From 3c695c02ac862da5e2f3fa484c235a25c32bf0c3 Mon Sep 17 00:00:00 2001 From: Nick Coghlan Date: Mon, 7 Mar 2011 22:09:55 +0000 Subject: [PATCH] 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. --- pep-0394.txt | 52 +++++++++++++++++++++++++++++++--------------------- 1 file changed, 31 insertions(+), 21 deletions(-) diff --git a/pep-0394.txt b/pep-0394.txt index bf7801c65..41c0447b7 100644 --- a/pep-0394.txt +++ b/pep-0394.txt @@ -20,8 +20,8 @@ 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`` 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 @@ Recommendation 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 @@ This is needed as, even though the majority of distributions still alias the 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 @@ 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. +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 @@ between the different Python versions when the Start menu shortcuts are 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