[issue21506] [Windows] installations should include pythonX.exe and pythonX.Y.exe executables

[Eryk Sun]

Eryk Sun <eryksun at gmail.com> added the comment:

One issues with versioned "X.Y" executables is interference with normal handling of the ".exe" extension. For example, in "python3.10" the ".10"  counts as an extension, so normally ".exe" won't be appended when searching for the name. 

This affects SearchPathW() searches that supply a default ".exe" extension, such as what CreateProcessW() uses to find the executable parsed from lpCommandLine. For example, subprocess.call('python3.9') won't append '.exe' to find "python3.9.exe" in the search path. 

It also affects the shell API's "App Paths" search, since the shell won't append ".exe" to a name that already has an extension. (The machine and user "App Paths" keys are the Windows shell equivalent of Unix "/usr/bin" and "$HOME/.local/bin", but more powerful.) For example, the store app distribution of Python 3.9 creates a "python3.9.exe" entry in the user's "App Paths", but os.startfile('python3.9') doesn't work; it has to be os.startfile('python3.9.exe').

Using "_" instead of "." would be compatible with Windows filename conventions -- e.g. "python3_10.exe". But this is an uphill battle against a Unix convention that's probably been in use since the 1970s or 1980s.

----------
components:  -Build
nosy: +paul.moore
title: Windows MSI installer should mklink (symlink) python.exe to python2.7.exe -> [Windows] installations should include pythonX.exe and pythonX.Y.exe executables
versions: +Python 3.10 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21506>
_______________________________________