[Python-checkins] r84775 - peps/trunk/pep-3149.txt

[barry.warsaw]

Author: barry.warsaw
Date: Mon Sep 13 16:18:43 2010
New Revision: 84775

Log:
Rephrase and emphasize inapplicability to Windows

Modified:
   peps/trunk/pep-3149.txt

Modified: peps/trunk/pep-3149.txt
==============================================================================
--- peps/trunk/pep-3149.txt	(original)
+++ peps/trunk/pep-3149.txt	Mon Sep 13 16:18:43 2010
@@ -68,15 +68,15 @@
 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
-library) packages into `/usr/share/pyshared` and symlink to them from
-`/usr/lib/pythonX.Y/dist-packages`.  The symlinks exist because in a
-pre-PEP 3147 world (i.e < Python 3.2), the `.pyc` files resulting from
-byte compilation by the various installed Pythons will name collide
-with each other.  For Python versions >= 3.2, all pure-Python packages
-can be shared, because the `.pyc` files will no longer cause file
-system naming conflicts.  Eliminating these symlinks makes for a
-simpler, more robust Python distribution.
+versions, these distributions install third party package modules
+(``.pyc`` and ``.so`` files) into `/usr/share/pyshared` and symlink to
+them from `/usr/lib/pythonX.Y/dist-packages`.  The symlinks exist
+because in a pre-PEP 3147 world (i.e < Python 3.2), the `.pyc` files
+resulting from byte compilation by the various installed Pythons will
+name collide with each other.  For Python versions >= 3.2, all
+pure-Python packages can be shared, because the `.pyc` files will no
+longer cause file system naming conflicts.  Eliminating these symlinks
+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 @@
 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 @@
 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/share/pyshared/foo.cpython-33m.so
+    /usr/lib/python/foo.cpython-32m.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 @@
 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
 =======