[Python-Dev] [PEPs] Rebooting PEP 394 (aka Support the /usr/bin/python2 symlink upstream) (original) (raw)

Kerrick Staley mail at kerrickstaley.com
Mon Jul 18 08:43:46 CEST 2011

Hi, These are two emails I sent a short while ago about finalizing PEP 394. There was no response, so in case the messages didn't go through, I'm resending them.

Thanks, Kerrick Staley

---------- Forwarded message ---------- From: Kerrick Staley <mail at kerrickstaley.com> Date: Sat, Jul 9, 2011 at 7:45 PM Subject: Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream To: python-dev at python.org

Sorry that I dropped the ball on this. I'd still like to see this get implemented, but I got distracted with school and forgot about it. Updates I have made to the PEP will be sent as a patch immediately after this email.

Here's a summary of what was happenening when we left off:

==== Here are my thoughts:

Also, #@ really ignores the purpose of a shebang: shebangs simply indicate an interpreter that works with the script; the shebang allows users to run arbitrary scripts without worrying about which interpreter they should specify. There's no reason that a script should use one interpreter on Unix, but be incompatible with that interpreter on Windows yet compatible with another. The name of the Unix binary is enough to determine the implementation and version of the interpreter to be used on Unix, and a Windows launcher should always invoke the same implementation/version on Windows (and this won't require hard-coding anything into the launcher if done right). If you want the script to run with a specific interpreter and version, possibly contingent on which operating system you're running the script under, then you can just invoke the interpreter by name with the script as an argument (e.g. python3 myprogram.py).

TL;DR: shebangs encode a default implementation/version, and if you need something special, you can just manually run python3 myprogram.py or use a .bat file.

==== Also, I updated the PEP with the clarification that commands like python3 should be hard links (because they'll be invoked from code and are more efficient; also, hard links are just as flexible as symlinks here), while commands like python should be soft links (because this makes it clear to sysadmins that they can be "switched", and it's needed for flexibility if python3 changes). This really doesn't matter, but can we keep it this way unless there are serious objections?

Regards, Kerrick Staley

---------- Forwarded message ---------- From: Kerrick Staley <mail at kerrickstaley.com> Date: Sat, Jul 9, 2011 at 7:46 PM Subject: Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream To: python-dev at python.org

$ svn diff Index: pep-0394.txt

--- pep-0394.txt (revision 88860) +++ pep-0394.txt (working copy) @@ -1,5 +1,5 @@ PEP: 394 -Title: The "python" command on Unix-Like Systems +Title: The "python" Command on Unix-Like Systems Version: RevisionRevisionRevision Last-Modified: DateDateDate Author: Kerrick Staley <mail at kerrickstaley.com>, @@ -53,10 +53,14 @@

These recommendations are the outcome of the relevant python-dev discussion in -March 2011 [1] (NOTE: More accurately, they will be such once that "Draft" -status disappears from the PEP header, it has been moved into the "Other +March to July 2011 [1] (NOTE: More accurately, they will be such once that +"Draft" status disappears from the PEP header, it has been moved into the "Other Informational PEP" section in PEP 0 and this note has been deleted)

@@ -144,11 +148,16 @@

While technically a new feature, 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. This feature will first appear in CPython 2.7.2. +python2.7, idle2.7, pydoc2.7, and python2.7-config binaries, +with python2, idle2, pydoc2, and python2-config as hard links +to the respective binaries, and python, idle, pydoc, and +python-config as symbolic links to the respective hard links. This feature +will first appear in CPython 2.7.2.

-The make install command in the CPython 3.x series will continue to -install only the python3 symlink for the foreseeable future. +The make install command in the CPython 3.x series will similarly install +the python3.x, idle3.x, pydoc3.x, and python3.x-config binaries +(with appropriate x), and python3, idle3, pydoc3, and +python3-config as hard links.

Impact on PYTHON* Environment Variables @@ -166,27 +175,12 @@ Exclusions of MS Windows

-This PEP deliberately excludes any proposals relating to Microsoft Windows. -The use of parallel installs on Windows suffers from numerous issues, -including the "last installed wins" behaviour for handling of file -associations, a lack of universal robust symlink support for easy aliasing of -commands, the fact that the Python executable is not available on PATH by -default, the fact that the python.exe and pythonw.exe names are -used for both Python 2 and Python 3 binaries and the lack of distinction -between the different Python versions when the Start menu shortcuts are -divorced from their containing folders (e.g. when they appear in the -"Recently Used" list. +This PEP deliberately excludes any proposals relating to Microsoft Windows: +devising an equivalent solution for Windows was deemed too complex to handle +here. PEP 397 and the related discussion on the python-dev mailing list address +this issue.

-While these questions are well worth addressing, they do not have easy -answers. The authors of this particular PEP aren't inclined to even begin -trying to answer them, but anyone that wants to tackle them should feel free -to start working on their own PEP.

-Note that, while the topic has been excluded from this PEP, there is plenty of -material in the linked python-dev discussion that may be useful in the design -and implementation of a Windows-specific solution.

More information about the Python-Dev mailing list