PEP 394: Allow the `python` command to not be installed, and other minor edits (GH-630)

* Allow the `python` command to not be installed, and other minor edits

- Distributions can omit the ``python`` command even when
  ``python2`` is installed in test environments, build systems,
  and other controlled environments where being explicit is
  valued more than user experience.
- Users, by a deliberate action, change
  ``python`` to invoke Python 3. Activating a venv counts as
  such an action.
- Other edits and clarifications

* Add myself as an author

pep-0394.txt

@@ -4,7 +4,8 @@ Version: $Revision$
 Last-Modified: $Date$
 Author: Kerrick Staley <mail@kerrickstaley.com>,
         Nick Coghlan <ncoghlan@gmail.com>,
-        Barry Warsaw <barry@python.org>
+        Barry Warsaw <barry@python.org>,
+        Petr Viktorin <encukou@gmail.com>
 Status: Active
 Type: Informational
 Content-Type: text/x-rst
@@ -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``
+* for the time being, all distributions *should* ensure that ``python``,
-  refers to the same target as ``python2``.
+  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
@@ -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
+* If the ``python`` command is installed, it should invoke the same version of
-  any version of Python 2 is installed and 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).
@@ -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
+  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.
 
 These recommendations are the outcome of the relevant python-dev discussions
-in March and July 2011 ([1]_, [2]_), February 2012 ([4]_) and
+in March and July 2011 ([1]_, [2]_), February 2012 ([4]_),
-September 2014 ([6]_).
+September 2014 ([6]_), and discussion on GitHub in April 2018 ([7]_).
 
 
 Rationale
@@ -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
@@ -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
+* It is strongly encouraged that distribution-specific packages use ``python2``
-  ``python2``/``python3`` convention, even in code that is not intended to
+  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
+  default.
-  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
@@ -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.