classification
Title: Launcher for Windows (py.exe) may rank Python 3.xx (in the future) after 3.x
Type: behavior Stage: resolved
Components: Windows Versions: Python 3.10
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: steve.dower Nosy List: ZackerySpytz, gvanrossum, paul.moore, steve.dower, tim.golden, ynyyn, zach.ware
Priority: normal Keywords: patch

Created on 2019-10-17 14:31 by ynyyn, last changed 2020-11-16 22:03 by steve.dower. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 18307 merged ZackerySpytz, 2020-02-02 06:43
Messages (9)
msg354843 - (view) Author: Yi Nian (ynyyn) Date: 2019-10-17 14:31
I, for interest, read some of source code of Python launcher, and found it used string comparison function (`wcscmp()`, in function `compare_pythons()`) to sort Python version in descending order.

It works well currently. But if Python 3.10 or Python 3.xx comes up in the future, Python 3.xx will be ranked after 3.x.

I modified the Registry and made a fake version Python 3.10, to check the launcher's behaviour.

```
PS > py -0p
Installed Pythons found by C:\Windows\py.exe Launcher for Windows
 -3.8-64        D:\Program Files\Python38\python.exe *
 -3.7-64        D:\Program Files\Python37\python.exe
 -3.7-32        D:\Program Files (x86)\Python37-32\python.exe
 -3.6-32        C:\Program Files (x86)\Python36-32\python.exe
 -3.10-64       D:\Program Files\Python37\python.exe
 -2.7-64        C:\python27-x64\python.exe
```

The result turned out that Python 3.10 was really ranked after 3.x.

And it seems that Python 3.xx should be a valid (or supported) version according to the comment from function `validate_version()`.


```
static BOOL
validate_version(wchar_t * p)
{
    /*
    Version information should start with the major version,
    Optionally followed by a period and a minor version,
    Optionally followed by a minus and one of 32 or 64.
    Valid examples:
      ...
      2.7-32
      The intent is to add to the valid patterns:
      3.10
      3-32
      ...
    */

I am not sure whether this is a potential defect that had been confirmed before... But I do not see some relevant comments in the source code.
msg354846 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-10-17 15:15
You're right that this will need fixing. But we don't really have to fix it any earlier than 3.10 - the launcher is backwards-compatible but not necessarily forwards-compatible. Still, we can take a fix whenever.

Probably it should just change to using CompareStringEx with (at least) the SORT_DIGITSASNUMBERS flag.

https://docs.microsoft.com/windows/win32/api/stringapiset/nf-stringapiset-comparestringex
msg381061 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2020-11-16 04:07
I think now's the time to fix it, given that we're two alphas into 3.10 already. (I independently discovered this and filed it as issue 42365.)
msg381063 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2020-11-16 04:12
Hm, actually I think this needs to be backported to 3.8 and 3.9 (at least) since IIUC whichever release is installed last (or first?) overwrites "py.exe", so if "py.exe" came from e.g. 3.9, and 3.10 is present, we still want it to sort that correctly.
msg381117 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2020-11-16 16:42
We can backport it, but the latest version always wins. I deliberately designed the installer (which has multiple embedded MSIs in it) to make sure this worked, so that earlier versions won't overwrite the launcher (anymore).

Besides, this is a purely cosmetic change. PEP 514 describes how to programmatically get the list of versions (i.e. without using py.exe at all).
msg381118 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2020-11-16 16:44
You may call it cosmetic, but for me it's a matter of usability.

Nevertheless, given how you designed the installer, we can drop the backport.
msg381131 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2020-11-16 17:35
It's cosmetic in the sense that it *only* affect usability, and not correctness.

If it had no impact at all, I'd be calling it "pointless" ;)
msg381165 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2020-11-16 21:32
New changeset f62dad16b8e540486a0a0fed41e723d36986f860 by Zackery Spytz in branch 'master':
bpo-38506: Fix the Windows py.exe launcher's misordering of 3.10 (GH-18307)
https://github.com/python/cpython/commit/f62dad16b8e540486a0a0fed41e723d36986f860
msg381169 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2020-11-16 22:03
Thanks for the patch, Zackery!
History
Date User Action Args
2020-11-16 22:03:57steve.dowersetstatus: open -> closed
messages: + msg381169

assignee: steve.dower
resolution: fixed
stage: patch review -> resolved
2020-11-16 21:32:45steve.dowersetmessages: + msg381165
2020-11-16 17:35:02steve.dowersetmessages: + msg381131
2020-11-16 16:45:04gvanrossumsetversions: - Python 3.8, Python 3.9
2020-11-16 16:44:51gvanrossumsetmessages: + msg381118
2020-11-16 16:42:24steve.dowersetmessages: + msg381117
2020-11-16 04:12:24gvanrossumsetmessages: + msg381063
versions: + Python 3.8, Python 3.9
2020-11-16 04:09:42gvanrossumsetversions: + Python 3.10, - Python 3.9
2020-11-16 04:07:58gvanrossumsetnosy: + gvanrossum
messages: + msg381061
2020-02-05 02:58:15ZackerySpytzsetnosy: + ZackerySpytz
2020-02-02 06:43:46ZackerySpytzsetkeywords: + patch
stage: test needed -> patch review
pull_requests: + pull_request17684
2019-10-17 15:15:58steve.dowersetstage: test needed
messages: + msg354846
versions: - Python 3.7, Python 3.8
2019-10-17 14:31:04ynyyncreate