Move PEP 405 to Accepted state.

pep-0405.txt

@@ -4,7 +4,7 @@ Version: $Revision$
 Last-Modified: $Date$
 Author: Carl Meyer <carl@oddbird.net>
 BDFL-Delegate: Nick Coghlan
-Status: Draft
+Status: Accepted
 Type: Standards Track
 Content-Type: text/x-rst
 Created: 13-Jun-2011
@@ -284,15 +284,15 @@ Include files
 
 Current virtualenv handles include files in this way:
 
-On POSIX systems where the installed Python's include files are found
-in ``${base_prefix}/include/pythonX.X``, virtualenv creates
-``${venv}/include/`` and symlink ``${base_prefix}/include/pythonX.X``
+On POSIX systems where the installed Python's include files are found in
+``${base_prefix}/include/pythonX.X``, virtualenv creates
+``${venv}/include/`` and symlinks ``${base_prefix}/include/pythonX.X``
 to ``${venv}/include/pythonX.X``. On Windows, where Python's include
 files are found in ``{{ sys.prefix }}/Include`` and symlinks are not
 reliably available, virtualenv copies ``{{ sys.prefix }}/Include`` to
 ``${venv}/Include``. This ensures that extension modules built and
-installed within the virtualenv will always find the Python header
-files they need in the expected location relative to ``sys.prefix``.
+installed within the virtualenv will always find the Python header files
+they need in the expected location relative to ``sys.prefix``.
 
 This solution is not ideal when an extension module installs its own
 header files, as the default installation location for those header
@@ -468,8 +468,8 @@ site-packages directories.
 The most notable case is probably `setuptools`_ and its fork
 `distribute`_, which mostly use ``distutils`` and ``sysconfig`` APIs,
 but do use ``sys.prefix`` directly to build up a list of site
-directories for pre-flight checking where ``pth`` files can usefully
-be placed.
+directories for pre-flight checking where ``pth`` files can usefully be
+placed.
 
 Otherwise, a `Google Code Search`_ turns up what appears to be a
 roughly even mix of usage between packages using ``sys.prefix`` to