[Python-checkins] r88766 - peps/trunk/pep-0394.txt
nick.coghlan
python-checkins at python.org
Mon Mar 7 23:09:55 CET 2011
Author: nick.coghlan
Date: Mon Mar 7 23:09:55 2011
New Revision: 88766
Log:
Reword a few things to make it clear that switching to Python 3 as the default interpreter is still bleeding edge stuff at this point in time. Also clarify the Windows situation a little more.
Modified:
peps/trunk/pep-0394.txt
Modified: peps/trunk/pep-0394.txt
==============================================================================
--- peps/trunk/pep-0394.txt (original)
+++ peps/trunk/pep-0394.txt Mon Mar 7 23:09:55 2011
@@ -20,8 +20,8 @@
* ``python2`` will refer to some version of Python 2.x
* ``python3`` will refer to some version of Python 3.x
-* ``python`` will refer to the same target as either ``python2`` or
- ``python3``, depending on the specific distribution and system
+* ``python`` *should* refer to the same target as ``python2`` but *may*
+ refer to ``python3`` on some bleeding edge distributions
Recommendation
@@ -38,9 +38,8 @@
any version of Python is installed and should invoke the same version of
Python as either ``python2`` or ``python3``.
* For the time being, it is recommended that ``python`` should refer to
- ``python2``, except on distributions which include only ``python3`` in their
- base install, or those that wish to push strongly for migration of user
- scripts to Python 3.
+ ``python2`` (however, some distributions have already chosen otherwise; see
+ Notes below).
* In order to tolerate differences across platforms, 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
@@ -69,24 +68,28 @@
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 directly rather than via ``sys.executable``) to reliably run on
-all systems without modification, as the ``python`` command will invoke the
-wrong interpreter version on some systems, and the ``python2`` command will
-fail completely on others. 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.
+all Unix-like systems without modification, as the ``python`` command will
+invoke the wrong interpreter version on some systems, and the ``python2``
+command will fail completely on others. 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
- version chosen should also be available via either the ``python2`` or
- ``python3`` command as appropriate.
+* Distributions that only include ``python3`` in their base install (i.e.
+ they do not provide ``python2`` by default) along with those that are
+ aggressively trying to reach that point (and are willing to break third
+ party scripts while attempting to get there) are already beginning to alias
+ the ``python`` command to ``python3``
+* More conservative distributions that are less willing to tolerate breakage
+ of third party scripts continue to alias it to ``python2``. Until the
+ conventions described in this PEP are more widely adopted, having ``python``
+ invoke ``python2`` will remain the recommended option.
* The ``pythonX.X`` (e.g. ``python2.6``) commands 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
+ can be useful 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
@@ -130,7 +133,10 @@
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.
+create these symbolic links and avoid further problems. It is a significantly
+more obvious breakage than the sometimes cryptic errors that can arise when
+attempting to execute a script containing Python 2 specific syntax with a
+Python 3 interpreter.
Application to the CPython Reference Interpreter
@@ -171,10 +177,14 @@
divorced from their containing folders (e.g. when they appear in the
"Recently Used" list.
-While these are questions well worth addressing, they do not have easy
-answers. The authors of this particular PEP aren't even inclined to try to
-begin answering them, but anyone that wants to tackle them should feel free
-to start working on their own PEP :)
+While these questions are well worth addressing, they do not have easy
+answers. The authors of this particular PEP aren't inclined to even begin
+trying to answer them, but anyone that wants to tackle them should feel free
+to start working on their own PEP.
+
+Note that, while the topic has been excluded from this PEP, there is plenty of
+material in the linked python-dev discussion that may be useful in the design
+and implementation of a Windows-specific solution.
References
More information about the Python-checkins
mailing list