Update based on Kerrick's latest changes

pep-0394.txt

@@ -1,5 +1,5 @@
 PEP: 394
-Title: The "python" command on Unix-Like Systems
+Title: The "python" Command on Unix-Like Systems
 Version: $Revision$
 Last-Modified: $Date$
 Author: Kerrick Staley <mail@kerrickstaley.com>,
@@ -8,7 +8,7 @@ Status: Draft
 Type: Informational
 Content-Type: text/x-rst
 Created: 02-Mar-2011
-Post-History: 04-Mar-2011
+Post-History: 04-Mar-2011, 20-Jul-2011
 
 
 Abstract
@@ -40,6 +40,11 @@ Recommendation
 * For the time being, it is recommended that ``python`` should refer to
   ``python2`` (however, some distributions have already chosen otherwise; see
   Notes below).
+* The Python 2.x ``idle``, ``pydoc``, and ``python-config`` commands should
+  likewise be available as ``idle2``, ``pydoc2``, and ``python2-config``,
+  with the original commands invoking these versions by default, but possibly
+  invoking the Python 3.x versions instead if configured to do so by the
+  system administrator.
 * 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
@@ -55,9 +60,9 @@ Recommendation
   interpreter location remains the preferred approach.
 
 These recommendations are the outcome of the relevant python-dev discussion in
-March 2011 [1] (NOTE: More accurately, they will be such once that "Draft"
+March and July 2011 [1][2] (NOTE: More accurately, they will be such once the
-status disappears from the PEP header, it has been moved into the "Other
+"Draft" status disappears from the PEP header, it has been moved into the
-Informational PEP" section in PEP 0 and this note has been deleted)
+"Other Informational PEP" section in PEP 0 and this note has been deleted)
 
 
 Rationale
@@ -142,13 +147,25 @@ Python 3 interpreter.
 Application to the CPython Reference Interpreter
 ================================================
 
-While technically a new feature, the ``make install`` command and the Mac OS
+While technically a new feature, the ``make install`` command in the 2.7
-X installer in the 2.7 version of CPython will be adjusted to create the
+version of CPython will be adjusted to create the ``python2.7``, ``idle2.7``,
-new ``python2`` command in addition to the existing ``python`` and
+``pydoc2.7``, and ``python2.7-config`` binaries, with ``python2``, ``idle2``,
-``python2.7`` commands. This feature will first appear in CPython 2.7.2.
+``pydoc2``, and ``python2-config`` as hard links to the respective binaries,
+and ``python``, ``idle``, ``pydoc``, and ``python-config`` as symbolic links
+to the respective hard links.  This feature will first appear in CPython
+2.7.3.
 
-The ``make install`` command in the CPython 3.x series will continue to
+The ``make install`` command in the CPython 3.x series will similarly install
-install only the ``python3`` symlink for the foreseeable future.
+the ``python3.x``, ``idle3.x``, ``pydoc3.x``, and ``python3.x-config``
+binaries (with appropriate ``x``), and ``python3``, ``idle3``, ``pydoc3``,
+and ``python3-config`` as hard links. This feature will first appear in
+CPython 3.3.
+
+Similar adjustments will be made to the Mac OS X binary installer.
+
+As implementation of these features in the default installers does not alter
+the recommendations in this PEP, the implementation progress is managed on the
+tracker as issue <TBD>.
 
 
 Impact on PYTHON* Environment Variables
@@ -163,28 +180,13 @@ tolerant of the presence of multiple versions of Python on a system than the
 direct use of ``PYTHONPATH``.
 
 
-Exclusions of MS Windows
+Exclusion of MS Windows
-========================
+=======================
 
-This PEP deliberately excludes any proposals relating to Microsoft Windows.
+This PEP deliberately excludes any proposals relating to Microsoft Windows, as
-The use of parallel installs on Windows suffers from numerous issues,
+devising an equivalent solution for Windows was deemed too complex to handle
-including the "last installed wins" behaviour for handling of file
+here. PEP 397 and the related discussion on the python-dev mailing list
-associations, a lack of universal robust symlink support for easy aliasing of
+address this issue.
-commands, the fact that the Python executable is not available on ``PATH`` by
-default, the fact that the ``python.exe`` and ``pythonw.exe`` names are
-used for both Python 2 and Python 3 binaries and the lack of distinction
-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 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
@@ -193,6 +195,9 @@ References
 [1] Support the /usr/bin/python2 symlink upstream (with bonus grammar class!)
     (http://mail.python.org/pipermail/python-dev/2011-March/108491.html)
 
+[2] Rebooting PEP 394 (aka Support the /usr/bin/python2 symlink upstream)
+    (http://mail.python.org/pipermail/python-dev/2011-July/112322.html)
+
 
 Copyright
 ===========