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

[Kerrick Staley]

Some nitpicks:

'The "python" command on Unix-Like Systems':
This should be 'The "python" Command on Unix-Like Systems'

"python will refer to the same target as either python2 or python3,
depending on the specific distribution and system":
Nothing should break if python isn't the same as either python2 or python3
(sysadmins might want to set something like this up), so let's change it to
"python will refer to some version of either Python 2.x or Python 3.x".
Similarly, "the same version of Python as either python2 or python3" should
be "some version of either Python 2.x or Python 3.x".

"For the time being, it is recommended that python should refer to python2,
except on distributions which include only python3 in their base install, or
those that wish to push strongly for migration of user scripts to Python
3.":
This bullet should be removed, since it unnecessarily lengthens the
Recommendation (the same topic is addressed in the first bullet of the
Notes) and is intended to be less strongly suggested than the other points
in the Recommendation.

"...all new code...":
take out "new"; we would also like existing code to be modified when
possible.

"the make install command and the Mac OS X installer in the 2.7 version of
CPython will be adjusted to create the new python2 command in addition to
the existing python and python2.7 commands":
Are we going to specify which is the symbolic link and which is the actual
executable? Per the 5th point in the Notes, I think that python should be a
symlink (does the default installer do this already, placing the executable
in pythonX.X?), since creating it as a link has advantages over an
executable in certain situations, but the reverse is not true.

"directly rather than via sys.executable":
This snippet is unneeded and confusing, because the "or any code that
invokes the Python 2 interpreter" parenthetical note is intended to address
code in other languages that execute the interpreter and not Python code.

"As an alternative to the recommendation presented above, some distributions
may choose to leave the python command itself undefined, leaving sysadmins
and users with the responsibility to choose their own preferred version to
be made available as the python command.":
The original version of this statement only addressed systems that have
traditionally left python undefined (OpenBSD apparently does this). As it's
worded now, it creates the possibility that distributions will suddenly
start leaving python undefined as a result of this PEP, to the vexation of
end-users.

The "Exclusions of MS Windows" section should be shortened to "This PEP
deliberately excludes any proposals relating to Microsoft Windows, due to
multiple issues in implementing a similar solution." This is because this
PEP is about the solution on Unix-Like systems; the discussion of the issue
on other platforms adds unnecessary length. The ideas in this section are
preserved in this discussion thread (which is referenced in the PEP) and the
verbatim text will still exist in the SVN, so anyone who needs this
information can still get it easily if it is deleted. Although I am
unfamiliar with Windows and am thus unaware of all the issues and possible
solutions, I think that an excellent solution for the Python 2/3 issue on
Windows was that suggested by Michael Foord: "...a stub python.exe that
looks at the shebang line and then delegates to the appropriate
pythonX.Y.exe would be a possibility..." However, implementing this solution
will take time and will slow the finalization of a solution for Unix-like
systems if it is included in this PEP.

-Kerrick Staley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110306/24a8cb03/attachment.html>