[Python-checkins] r88743 - peps/trunk/pep-0394.txt

Fri Mar 4 13:04:22 CET 2011

Author: nick.coghlan
Date: Fri Mar 4 13:04:22 2011
New Revision: 88743
Log:
Add proposed PEP for *nix command naming conventions
Added:
 peps/trunk/pep-0394.txt (contents, props changed)
Added: peps/trunk/pep-0394.txt
==============================================================================

--- (empty file)
+++ peps/trunk/pep-0394.txt	Fri Mar 4 13:04:22 2011
@@ -0,0 +1,124 @@
+PEP: 394
+Title: The "python" command on Unix-Like Systems
+Version: $Revision$
+Last-Modified: $Date$
+Author: Kerrick Staley <mail at kerrickstaley.com>,
+ Nick Coghlan <ncoghlan at gmail.com>
+Status: Draft
+Type: Informational
+Content-Type: text/x-rst
+Created: 02-Mar-2011
+Post-History: 04-Mar-2011
+
+
+Abstract
+========
+
+This PEP provides a convention to ensure that Python scripts can continue to
+be portable across ``*nix`` systems, regardless of the default version of the
+Python interpreter (i.e. the version invoked by the ``python`` command).
+
+* ``python2`` will refer to some version of Python 2.x
+* ``python3`` will refer to some version of Python 3.x
+* ``python`` may refer to either, depending on distribution and system
+
+
+Recommendation
+==============
+
+* ``*nix`` software distributions should install the ``python2`` command into
+ the default path whenever a version of the Python 2 interpreter is
+ installed, and the same for ``python3`` and the Python 3 interpreter. When
+ invoked, ``python2`` should run some version of the Python 2 interpreter,
+ and ``python3`` should run some version of the Python 3 interpreter. The
+ same applies for the more general ``python`` command, which should be
+ installed whenever any version of Python is installed and should invoke
+ some Python interpreter.
+* All new code that needs to invoke the Python interpreter should not specify
+ ``python``, but rather should specify either ``python2`` or ``python3`` (or
+ the more specific ``python2.x`` and ``python3.x`` versions; see the Notes).
+ This distinction should be made in shebangs, when invoking from a shell
+ script, when invoking via the system() call, or when invoking in any other
+ context. Note that, when reinvoking the interpreter from a Python script,
+ querying ``sys.executable`` remains the preferred approach.
+
+
+Rationale
+=========
+
+This is needed as, even though the majority of distributions still alias the
+``python`` command to Python 2, some now alias it to Python 3. Some of
+the former also do not provide a ``python2`` command; hence, there is
+currently no way for Python 2 code (or any code that invokes the Python 2
+interpreter) to reliably run on all systems without modification, because both
+the ``python`` and the ``python2`` commands will fail on some systems. The
+recommendations in this PEP provide a very simple mechanism to restore
+cross-platform support, with minimal additional work required on the part
+of distribution maintainers.
+
+
+Notes
+=====
+
+* Distributions can alias the ``python`` command to whichever version of the
+ Python interpreter they choose (noting that, in the near term, most 3rd
+ party scripts will still expect this command to refer to Python 2.x).
+* The ``pythonX.X`` (e.g. ``python2.6``) utilities exist on some systems, on
+ which they invoke specific minor versions of the Python interpreter. It
+ would be wise for distribution-specific packages to take advantage of these
+ utilities if they exist, since it will prevent code breakage if the default
+ minor version of a given major version is changed. However, scripts
+ intending to be cross-platform should not rely on the presence of these
+ utilities, but rather should be tested on several recent minor versions of
+ the target major version, compensating, if necessary, for the small
+ differences that exist between minor versions. This prevents the need for
+ sysadmins to install many very similar versions of the interpreter.
+* It would be wise for distribution-specific packages to always follow the
+ ``python2``/``python3`` convention, even in code that is not intended to
+ operate on other distributions. This will prevent problems if the
+ distribution later decides to upgrade the version of the Python interpreter
+ that the ``python`` command invokes, or if a sysadmin installs a custom
+ ``python`` command with a different major version than the distribution
+ default. Distributions can test whether they are fully following this
+ convention by changing the ``python`` interpreter on a test box and checking
+ to see if anything breaks.
+* If the above point is adhered to and sysadmins are permitted to change the
+ ``python`` command, then the ``python`` command should always be implemented
+ as a link to the interpreter binary (or a link to a link) and not vice
+ versa. That way, if a sysadmin does decide to replace the installed
+ ``python`` file, they can do so without inadvertently deleting the
+ previously installed binary.
+* The first recommendation can be ignored for systems on which the ``python``
+ command itself has traditionally been left undefined and users have always
+ had the responsibility of linking the ``python`` command to the Python
+ interpreter.
+* If the Python 2 interpreter becomes uncommon, scripts should nevertheless
+ continue to use the ``python3`` convention rather that just ``python``. This
+ will ease transition in the event that yet another major version of Python
+ is released.
+* If these conventions are adhered to, it will be the case that the ``python``
+ command is only executed in an interactive manner.
+
+
+Backwards Compatibility
+=========================
+
+A potential problem can arise if a script adhering to the
+``python2``/``python3`` convention is executed on a system not supporting
+these commands. This is mostly a non-issue, since the sysadmin can simply
+create these symbolic links and avoid further problems.
+
+Application to the CPython Reference Interpreter
+================================================
+
+While technically a new feature, the ``make install`` command of the 2.7
+version of CPython will be adjusted to create the ``python2`` symlink in
+addition to the existing ``python`` symlink. 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.
+
+Copyright
+===========
+This document has been placed in the public domain.
