Skip to content

PEP 394: Allow the python command to not be installed, and other minor edits #630

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Apr 28, 2018
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 32 additions & 18 deletions pep-0394.txt
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,8 @@ Version: $Revision$
Last-Modified: $Date$
Author: Kerrick Staley <[email protected]>,
Nick Coghlan <[email protected]>,
Barry Warsaw <[email protected]>
Barry Warsaw <[email protected]>,
Petr Viktorin <[email protected]>
Status: Active
Type: Informational
Content-Type: text/x-rst
Expand All @@ -22,8 +23,9 @@ 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.
* for the time being, all distributions *should* ensure that ``python``
refers to the same target as ``python2``.
* for the time being, all distributions *should* ensure that ``python``,
if installed, refers to the same target as ``python2``, unless the user
deliberately overrides this or a virtual environment is active.
* however, end users should be aware that ``python`` refers to ``python3``
on at least Arch Linux (that change is what prompted the creation of this
PEP), so ``python`` should be used in the shebang line only for scripts
Expand All @@ -43,8 +45,7 @@ Recommendation
* When invoked, ``python2`` should run some version of the Python 2
interpreter, and ``python3`` should run some version of the Python 3
interpreter.
* The more general ``python`` command should be installed whenever
any version of Python 2 is installed and should invoke the same version of
* If the ``python`` command is installed, it should invoke the same version of
Python as the ``python2`` command (however, note that some distributions
have already chosen to have ``python`` implement the ``python3``
command; see the `Rationale`_ and `Migration Notes`_ below).
Expand All @@ -62,14 +63,30 @@ Recommendation
context.
* One exception to this is scripts that are deliberately written to be source
compatible with both Python 2.x and 3.x. Such scripts may continue to use
``python`` on their shebang line without affecting their portability.
``python`` on their shebang line.
* When packaging software that is source compatible with both versions,
distributions may change such ``python`` shebangs to ``python3``.
This ensures software is used with the latest version of
Python available, and it can remove a dependency on Python 2.
* When reinvoking the interpreter from a Python script, querying
``sys.executable`` to avoid hardcoded assumptions regarding the
interpreter location remains the preferred approach.
* In controlled environments aimed at expert users, where being explicit
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes on this bullet.

is valued over user experience (for example, in test environments and
package build systems), distributions may choose to not provide the
``python`` command even if ``python2`` is available.
(All software in such a controlled environment must use ``python3`` or
``python2`` rather than ``python``, which means scripts that deliberately
use ``python`` need to be modified for such environments.)
* When a virtual environment (created by the PEP 405 ``venv`` package or a
similar tool) is active, the ``python`` command should refer to the
virtual environment's interpreter. In other words, activating a virtual
environment counts as deliberate user action to change the default
``python`` interpreter.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on this bullet point. Having python point to Python 3 when a Python 3 environment is activated is now established practice, and it would be nice for the PEP to acknowledge that. Many subparts of the community have already shifted away from the old idiom of relying on the system Python for user scripts.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I won't ask venv to change, I just rm <env>/bin/python after creating the env. :-) I wonder if it should say "may refer" rather than "should refer"?

I do note that this makes using #!/usr/bin/env python quite unreliable to invoke Python 2.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather keep "should". It's quite an engrained expectation by now to have python point to the environment's Python. Doing otherwise would break those expectations.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aye, this is definitely a should - we rely on it heavily in the Python Packaging User Guide.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK.


These recommendations are the outcome of the relevant python-dev discussions
in March and July 2011 ([1]_, [2]_), February 2012 ([4]_) and
September 2014 ([6]_).
in March and July 2011 ([1]_, [2]_), February 2012 ([4]_),
September 2014 ([6]_), and discussion on GitHub in April 2018 ([7]_).


Rationale
Expand All @@ -91,11 +108,6 @@ on the part of distribution maintainers.
Future Changes to this Recommendation
=====================================

It is anticipated that there will eventually come a time where the third
party ecosystem surrounding Python 3 is sufficiently mature for this
recommendation to be updated to suggest that the ``python`` symlink
refer to ``python3`` rather than ``python2``.

This recommendation will be periodically reviewed over the next few years,
and updated when the core development team judges it appropriate. As a
point of reference, regular maintenance releases for the Python 2.7 series
Expand Down Expand Up @@ -150,15 +162,13 @@ making such a change.
* When the ``pythonX.X`` binaries are provided by a distribution, the
``python2`` and ``python3`` commands should refer to one of those files
rather than being provided as a separate binary file.
* It is suggested that even distribution-specific packages follow the
``python2``/``python3`` convention, even in code that is not intended to
* It is strongly encouraged that distribution-specific packages use ``python2``
or ``python3`` rather than ``python``, even in code that is not intended to
operate on other distributions. This will reduce problems if the
distribution later decides to change 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.
default.
* 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
Expand Down Expand Up @@ -267,6 +277,10 @@ References
.. [6] PEP 394 - Clarification of what "python" command should invoke
(https://mail.python.org/pipermail/python-dev/2014-September/136374.html)

.. [7] PEP 394: Allow the `python` command to not be installed, and other
minor edits
(https://github.com/python/peps/pull/630)

Copyright
===========
This document has been placed in the public domain.