This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author steve.dower
Recipients jkloth, paul.moore, steve.dower, tim.golden, zach.ware
Date 2019-08-06.16:26:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1565108802.1.0.302823757641.issue37734@roundup.psfhosted.org>
In-reply-to
Content
It looks like the best solution here may be to rename the bundled executables to "python3.8.exe" etc. rather than "python.exe".

We will still keep the "python.exe" alias, and sys.executable won't change (it'll still point to the stable alias), but by having the "core" executable be named differently between Python versions it'll fix a couple of minor issues.

Most importantly here, because the registry path would then point at "python3.8.exe" rather than "python.exe", it becomes more likely that the global alias will remain enabled and so launching via the registry path will work. The downside is that apps that use "$InstallPath\python.exe" rather than "$ExecutablePath" will not work. But the ExecutablePath value has been present for a while now, and PEP 514 specifies it as preferred when available, so I think that's okay.

We can also include a plain "python[w].exe" in the installation, but that'll only be useful for subprocess.run("python") from the same version - it won't be executable at all from outside the app package.

(None of this affects the regular installer, FWIW. That'll still be plain "python.exe".)

Anyone have any thoughts or concerns?
History
Date User Action Args
2019-08-06 16:26:42steve.dowersetrecipients: + steve.dower, paul.moore, tim.golden, jkloth, zach.ware
2019-08-06 16:26:42steve.dowersetmessageid: <1565108802.1.0.302823757641.issue37734@roundup.psfhosted.org>
2019-08-06 16:26:42steve.dowerlinkissue37734 messages
2019-08-06 16:26:41steve.dowercreate