Add proposed PEP for *nix command naming conventions

pep-0394.txt

@@ -0,0 +1,124 @@
+PEP: 394
+Title: The "python" command on Unix-Like Systems
+Version: $Revision$
+Last-Modified: $Date$
+Author: Kerrick Staley <mail@kerrickstaley.com>,
+        Nick Coghlan <ncoghlan@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.