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.

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

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 bpo-42365.)

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.

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).

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.

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" ;)

New changeset f62dad1 by Zackery Spytz in branch 'master':
bpo-38506: Fix the Windows py.exe launcher's misordering of 3.10 (GH-18307)
f62dad1

Thanks for the patch, Zackery!