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

[Michael Foord]

On 04/03/2011 12:10, Nick Coghlan wrote:
> 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.

Should any of this also apply to Mac OS X and Windows?

Note that we *do* have alternative distributors [1] of Python for these 
platforms who may wish to follow any recommendations we have for 2.7, 
even if we don't modify those installers for our own distributions.

All the best,

Michael Foord

[1] Activestate and Enthought in particular. Plus possibly others I'm 
not aware of.

> 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.
>


-- 
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html