Add PEP 486 by Paul Moore.

Also, update Paul's email address.

pep-0250.txt

@@ -2,7 +2,7 @@ PEP: 250
 Title: Using site-packages on Windows
 Version: $Revision$
 Last-Modified: $Date$
-Author: gustav@morpheus.demon.co.uk (Paul Moore)
+Author: p.f.moore@gmail.com (Paul Moore)
 Status: Final
 Type: Standards Track
 Created: 30-Mar-2001

pep-0302.txt

@@ -3,7 +3,7 @@ Title: New Import Hooks
 Version: $Revision$
 Last-Modified: $Date$
 Author: Just van Rossum <just@letterror.com>,
-        Paul Moore <gustav@morpheus.demon.co.uk>
+        Paul Moore <p.f.moore@gmail.com>
 Status: Final
 Type: Standards Track
 Content-Type: text/x-rst

pep-0310.txt

@@ -3,7 +3,7 @@ Title: Reliable Acquisition/Release Pairs
 Version: $Revision$
 Last-Modified: $Date$
 Author: Michael Hudson <mwh@python.net>,
-        Paul Moore <gustav@morpheus.demon.co.uk>
+        Paul Moore <p.f.moore@gmail.com>
 Status: Rejected
 Type: Standards Track
 Content-Type: text/plain

pep-0486.txt

@@ -0,0 +1,149 @@
+PEP: 486
+Title: Make the Python Launcher aware of virtual environments
+Version: $Revision$
+Last-Modified: $Date$
+Author: Paul Moore <p.f.moore@gmail.com>
+Status: Draft
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 12-Feb-2015
+Python-Version: 3.5
+Post-History:
+
+
+Abstract
+========
+
+The Windows installers for Python include a launcher that locates the
+correct Python interpreter to run (see PEP 397).  However, the
+launcher is not aware of virtual environments (virtualenv [1]_ or PEP
+405 based), and so cannot be used to run commands from the active
+virtualenv.
+
+This PEP proposes making the launcher "virtualenv aware".  This means
+that when run without specifying an explicit Python interpreter to
+use, the launcher will use the currently active virtualenv, if any,
+before falling back to the configured default Python.
+
+
+Rationale
+=========
+
+Windows users with multiple copies of Python installed need a means of
+selecting which one to use.  The Python launcher provides this
+facility by means of a ``py`` command that can be used to run either a
+configured "default" Python or a specific interpreter, by means of
+command line arguments.  So typical usage would be::
+
+    # Run the Python interactive interpreter
+    py
+
+    # Execute an installed module
+    py -m pip install pytest
+    py -m pytest
+
+When using virtual environments, the ``py`` launcher is unaware that a
+virtualenv is active, and will continue to use the system Python.  So
+different command invocations are needed to run the same commands in a
+virtualenv::
+
+    # Run the Python interactive interpreter
+    python
+
+    # Execute an installed module (these could use python -m,
+    # which is longer to type but is a little mopre similar to the
+    # launcher approach)
+    pip install pytest
+    py.test
+
+Having to use different commands is is error-prone, and in many cases
+the error is difficult to spot immediately. The PEP proposes making
+the ``py`` command usable with virtual environments, so that the first
+form of command can be used in all cases.
+
+
+Implementation
+==============
+
+Both ``virtualenv`` and the core ``venv`` module set an environment
+variable ``VIRTUAL_ENV`` when activating a virtualenv.  This PEP
+proposes that the launcher checks for the ``VIRTUAL_ENV`` environment
+variable whenever it would run the "default" Python interpreter for
+the system (i.e., when no specific version flags such as ``py -2.7``
+are used) and if present, run the Python interpreter for the
+virtualenv rather than the default system Python.
+
+The "default" Python interpreter referred to above is (as per PEP 397)
+either the latest version of Python installed on the system, or
+a version configured via the ``py.ini`` configuration file.  When the
+user specifies an explicit Python version on the command line, this
+will always be used (as at present).
+
+
+Impact on Script Launching
+==========================
+
+As well as interactive use, the launcher is used as the Windows file
+association for Python scripts.  In that case, a "shebang" (``#!``)
+line at the start of the script is used to identify the interpreter to
+run.  A fully-qualified path can be used, or a version-specific Python
+(``python3`` or ``python2``, or even ``python3.5``), or the generic
+``python``, which means to use the default interpreter.
+
+With the proposed change, scripts that start with ``#!python`` (or one
+of its equivalent forms) will be run using an active virtualenv.  This
+is a change in behaviour, although it will only affect users running
+scripts from the command line with a virtualenv activated.
+
+Under Unix, the ``#!/usr/bin/env python`` shebang line will use the
+version of Python found on ``$PATH``, whereas ``#!/usr/bin/python``
+will use the system Python.  In order to match Unix behaviour as
+closely as possible, it is proposed that the two shebang forms::
+
+    #!/usr/bin/env python
+    #!python
+
+use an active virtualenv, if present, whereas the forms::
+
+    #!/usr/bin/python
+    #!/usr/local/bin/python
+
+use *only* the default system Python, and ignore the ``VIRTUAL_ENV``
+environment variable.
+
+
+Exclusions
+==========
+
+The PEP makes no attempt to promote the use of the launcher for
+running Python on Windows.  Most existing documentation assumes the
+user of ``python`` as the command to run Python, and (for example)
+``pip`` to run an installed Python command.  This documentation is not
+expected to change, and users who choose to manage their ``PATH``
+environment variable can continue to use this form.  The focus of this
+PEP is purely on allowing users who prefer to use the launcher when
+dealing with their system Python installations, to be able to continue
+to do so when using virtual environments.
+
+
+References
+==========
+
+.. [1] https://virtualenv.pypa.io/
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+
+
+..
+   Local Variables:
+   mode: indented-text
+   indent-tabs-mode: nil
+   sentence-end-double-space: t
+   fill-column: 70
+   coding: utf-8
+   End: