Rephrase and emphasize inapplicability to Windows

pep-3149.txt

@@ -68,15 +68,15 @@ Ubuntu 9.10 Karmic Koala users can install Python 2.5, 2.6, and 3.1,
 with Python 2.6 being the default.
 
 In order to share as much as possible between the available Python
-versions, these distributions install third party (i.e. non-standard
+versions, these distributions install third party package modules
-library) packages into `/usr/share/pyshared` and symlink to them from
+(``.pyc`` and ``.so`` files) into `/usr/share/pyshared` and symlink to
-`/usr/lib/pythonX.Y/dist-packages`.  The symlinks exist because in a
+them from `/usr/lib/pythonX.Y/dist-packages`.  The symlinks exist
-pre-PEP 3147 world (i.e < Python 3.2), the `.pyc` files resulting from
+because in a pre-PEP 3147 world (i.e < Python 3.2), the `.pyc` files
-byte compilation by the various installed Pythons will name collide
+resulting from byte compilation by the various installed Pythons will
-with each other.  For Python versions >= 3.2, all pure-Python packages
+name collide with each other.  For Python versions >= 3.2, all
-can be shared, because the `.pyc` files will no longer cause file
+pure-Python packages can be shared, because the `.pyc` files will no
-system naming conflicts.  Eliminating these symlinks makes for a
+longer cause file system naming conflicts.  Eliminating these symlinks
-simpler, more robust Python distribution.
+makes for a simpler, more robust Python distribution.
 
 A similar situation arises with shared library extensions.  Because
 extension modules are typically named `foo.so` for a `foo` extension
@@ -126,11 +126,6 @@ shared library file names would appear as ``foo.cpython-32m.so``.
 When the other two flags are also enabled, the file names would be
 ``foo.cpython-32dmu.so``.
 
-(This PEP only addresses build issues on POSIX systems that use the
-``configure`` script.  While Windows or other platform support is not
-explicitly disallowed under this PEP, platform expertise is needed in
-order to evaluate, describe, and implement support on such platforms.)
-
 The shared library file name tag is used unconditionally; it cannot be
 changed.  The tag and extension module suffix are available through
 the ``sysconfig`` modules via the following variables::
@@ -144,11 +139,16 @@ Note that ``$SOABI`` contains just the tag, while ``$SO`` includes the
 platform extension for shared library files, and is the exact suffix
 added to the extension module name.
 
-For an arbitrary package `foo`, you would see these files when the
+For an arbitrary package `foo`, you might see these files when the
 distribution package was installed::
 
-    /usr/share/pyshared/foo.cpython-32m.so
+    /usr/lib/python/foo.cpython-32m.so
-    /usr/share/pyshared/foo.cpython-33m.so
+    /usr/lib/python/foo.cpython-33m.so
+
+(These paths are for example purposes only.  Distributions are free to
+use whatever filesystem layout they choose, and nothing in this PEP
+changes the locations where from-source builds of Python are
+installed.)
 
 Python's dynamic module loader will recognize and import shared
 library extension modules with a tag that matches its build-time
@@ -173,6 +173,17 @@ encoded (in a different way than proposed in this PEP) the Python
 major and minor version in the `.dll` file name.
 
 
+Windows
+=======
+
+This PEP only addresses build issues on POSIX systems that use the
+``configure`` script.  While Windows or other platform support is not
+explicitly disallowed under this PEP, platform expertise is needed in
+order to evaluate, describe, and implement support on such platforms.
+It is not currently clear that the facilities in this PEP are even
+useful for Windows.
+
+
 PEP 384
 =======