-
-
Notifications
You must be signed in to change notification settings - Fork 31.6k
Launcher for Windows (py.exe) may rank Python 3.xx (in the future) after 3.x #82687
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I, for interest, read some of source code of Python launcher, and found it used string comparison function ( 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.
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
|
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" ;) |
Thanks for the patch, Zackery! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: