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

[Nick Coghlan]

On Fri, Mar 4, 2011 at 5:44 PM, Kerrick Staley <mail at kerrickstaley.com> wrote:
> PEP: ???
> Title: The python Utility on Unix-Like Systems

With a few adjustments (formatting, additional info, correction of
typos), I've now added Kerrick's PEP as a proposal on python.org:

http://www.python.org/dev/peps/pep-0394

The full text is included below as well.

Cheers,
Nick.

PEP: 394
Title: The "python" command on Unix-Like Systems
Version: $Revision: 88743 $
Last-Modified: $Date: 2011-03-04 22:04:22 +1000 (Fri, 04 Mar 2011) $
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.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia