<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><meta http-equiv="content-type" content="text/html; charset=utf-8">Some nitpicks:</div><div><br></div><div>'The "python" command on Unix-Like Systems':</div>
<div>This should be 'The "python" Command on Unix-Like Systems'</div><div><br></div>"python will refer to the same target as either python2 or python3, depending on the specific distribution and system":<br>
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".<div>
<span class="Apple-style-span" style="font-family: Arial, Verdana, Geneva, 'Bitstream Vera Sans', Helvetica, sans-serif; font-size: 15px; line-height: 21px; "><br></span></div><div><span class="Apple-style-span" style="font-family: Arial, Verdana, Geneva, 'Bitstream Vera Sans', Helvetica, sans-serif; font-size: 15px; line-height: 21px; "></span>"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.":</div>
<div>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.</div>
<div><br></div><div>"...all new code...":</div><div>take out "new"; we would also like existing code to be modified when possible.</div><div><br></div><div><div><div>"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":</div>
<div>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.</div>
</div><div><br></div>"directly rather than via sys.executable":<meta http-equiv="content-type" content="text/html; charset=utf-8"></div><div>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.</div>
<div><br></div>"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.":<meta http-equiv="content-type" content="text/html; charset=utf-8"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>
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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>-Kerrick Staley</div>