On 04/03/2011 12:10, Nick Coghlan wrote:
On Fri, Mar 4, 2011 at 5:44 PM, Kerrick Staley<m...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
