Eryk Sun <eryk...@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 <rep...@bugs.python.org>
<https://bugs.python.org/issue21506>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
