[Python-Dev] Support the /usr/bin/python2 symlink upstream

["Martin v. Löwis"]

>>> Should any of this also apply to Mac OS X and Windows?
>> Any platform that considers itself "unix-like" in this context can
>> decide to follow it, we aren't fussy (e.g. Cygwin and the *nix-y
>> aspects of OS X). The main point of the PEP is to get a consensus
>> recommendation out of python-dev as to the best way forward (and I
>> think Kerrick did a good job of summarising the position that has been
>> expressed in this thread).
>>
> Right, but the pep doesn't address those issues for some fairly major
> platforms.

Correct. IIUC (i.e. from the viewpoint of the PEP author), that's
deliberate. He just doesn't care about Windows, and, as a PEP author,
he clearly has the right to do so :-)

> 
>> More generally, Windows and Mac OS X developers seem to be happier
>> with the idea of bundling a Python interpreter inside the application
>> than traditional *nix style platforms. This is a PITA for the system
>> maintainer when it comes time to handle security vulnerabilites, but
>> certainly more convenient when upgrading the default Python install.
>>
> 
> However on Mac OS X at least *scripts* have the same issue (what to put
> in the shebang line).

IMO, MacOS does fall under the rule of the PEP - it is unixish.
I agree with all things that Nick said, in particular with the
observation that Apple will do what Apple will do, no matter how
many PEPs we write. Our own "make install", for OSX, should clearly
do something similar to what it does on other Unix systems.

> On Windows we only have a "python.exe" I believe, but if the user does
> put their Python installs on the path then we *could* usefully create
> "python2.exe" and "python3.exe" for them. I don't see that duplicating
> these binaries on the filesystem is an issue. File associations is just
> unsolvable on Windows, so it isn't something we can address or should
> worry about. (Actually a stub python.exe that looks at the shebang line
> and then delegates to the appropriate pythonX.Y.exe would be a
> possibility but I'm not volunteering to write it.)

Here I also agree with Nick: the binary file name might be the least
issue. We had one bug report about 2.x and 3.x interference so far that
was difficult to track down - it seems that many Python users on Windows
set PYTHONPATH, and that is going to break Python 3 installations.

With that problem, and the extension problem, solving the exe name issue
doesn't actually resolve real problems.

Regards,
Martin