iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Rephrase and emphasize inapplicability to Windows

This commit is contained in:
Barry Warsaw 2010-09-13 14:18:43 +00:00
parent f31bacb1af
commit 1d53ffb3cb
1 changed files with 28 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
pep-3149.txt
View File

@ -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
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 @@ 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/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 @@ 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
=======