Paul's latest revision, marked Finish, with minor formatting fixes.

Paul changed the name of the PEP so this will be reflected in PEP 0.

pep-0250.txt

@@ -1,10 +1,10 @@
 PEP: 250
-Title: Using site-packages on All Platforms
+Title: Using site-packages on Windows
 Version $Revision$
 Author: gustav@morpheus.demon.co.uk (Paul Moore)
-Status: Draft
+Status: Final
 Type: Standards Track
-Created: 2001-03-30
+Created: 30-Mar-2001
 Python-Version: 2.2
 Post-History: 30-Mar-2001
 
@@ -18,7 +18,7 @@ Abstract
     modules in the site-packages directory.
 
     This PEP proposes that the site-packages directory should be used
-    uniformly across all platforms for locally installed modules.
+    on the Windows platform in a similar manner.
 
 
 Motivation
@@ -26,9 +26,10 @@ Motivation
     On Windows platforms, the default setting for sys.path does not
     include a directory suitable for users to install locally
     developed modules.  The "expected" location appears to be the
-    directory containing the Python executable itself.  Including
+    directory containing the Python executable itself.  This is also
-    locally developed code in the same directory as installed
+    the location where distutils (and distutils-generated installers)
-    executables is not good practice.
+    installs packages.  Including locally developed code in the same
+    directory as installed executables is not good practice.
 
     Clearly, users can manipulate sys.path, either in a locally
     modified site.py, or in a suitable sitecustomize.py, or even via
@@ -71,10 +72,17 @@ Implementation
         else:
             sitedirs == [prefix, makepath(prefix, "lib", "site-packages")]
 
-    Changes would also be required to distutils, in the sysconfig.py
+    Changes would also be required to distutils, to reflect this change
-    file.  It is worth noting that this file does not seem to have
+    in policy. A patch is available on Sourceforge, patch ID 445744,
-    been updated in line with the change of policy on the Macintosh,
+    which implements this change.  Note that the patch checks the Python
-    as of this writing.
+    version and only invokes the new behaviour for Python versions from
+    2.2 onwards. This is to ensure that distutils remains compatible
+    with earlier versions of Python.
+
+    Finally, the executable code which implements the Windows installer
+    used by the bdist_wininst command will need changing to use the new
+    location.  A separate patch is available for this, currently
+    maintained by Thomas Heller.
 
 
 Notes
@@ -85,7 +93,7 @@ Notes
 
     - Both the current location (sys.prefix) and the new directory
       (site-packages) are included in sitedirs, so that .pth files
-      will be recognized in either location.
+      will be recognised in either location.
 
     - This proposal adds a single additional site-packages directory
       to sitedirs. On Unix platforms, two directories are added, one
@@ -96,25 +104,25 @@ Notes
       common location available on Windows, there is also no need for
       having two separate package directories.
 
-    - If users want to keep DLLs in a single location on Windows,
+    - If users want to keep DLLs in a single location on Windows, rather
-      rather than keeping them in the package directory, the DLLs
+      than keeping them in the package directory, the DLLs subdirectory
-      subdirectory of the Python install directory is available for
+      of the Python install directory is already available for that
-      that purpose. Adding an extra directory solely for DLLs should
+      purpose. Adding an extra directory solely for DLLs should not be
-      not be necessary.
+      necessary.
 
 
 Open Issues
 
-    - There have been no comments on this proposal from non-Windows
+    - Comments from Unix users indicate that there may be issues with
-      users. In the absence of such comments, it is assumed that there
+      the current setup on the Unix platform.  Rather than become
-      will be no adverse effects on such platforms caused by the
+      involved in cross-platform issues, this PEP specifically limits
-      proposed change. (The author knows of no reason why there should
+      itself to the Windows platform, leaving changes for other platforms
-      be).
+      to be covered inother PEPs.
 
-    - There could be issues with applications which embed Python. To
+    - There could be issues with applications which embed Python. To the
-      the author's knowledge, there should be no problem as a result
+      author's knowledge, there should be no problem as a result of this
-      of this change. Again, there have been no comments (supportive
+      change. There have been no comments (supportive or otherwise) from
-      or otherwise) from users who embed Python.
+      users who embed Python.
 
 
 Copyright