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

PEP 3149: Resolve uses of the default role (#3401)

This commit is contained in:
Adam Turner 2023-09-01 20:27:45 +01:00 committed by GitHub
parent 96480c49e4
commit 76159afb05
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
pep-3149.txt
View File

@ -30,8 +30,8 @@ Background
:pep:`3147` defined the file system layout for a pure-Python package,
where multiple versions of Python are available on the system. For
example, where the `alpha` package containing source modules `one.py`
and `two.py` exist on a system with Python 3.2 and 3.3, the post-byte
example, where the ``alpha`` package containing source modules ``one.py``
and ``two.py`` exist on a system with Python 3.2 and 3.3, the post-byte
compilation file system layout would be::
alpha/
@ -69,18 +69,18 @@ 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 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
(``.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
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
module, these would also name collide if `foo` was provided for more
extension modules are typically named ``foo.so`` for a ``foo`` extension
module, these would also name collide if ``foo`` was provided for more
than one Python version.
In addition, because different configuration/compilation options for
@ -93,7 +93,7 @@ module files.
PyPy [5]_ can also benefit from this PEP, allowing it to avoid name
collisions in extension modules built for its API, but with a
different `.so` tag.
different ``.so`` tag.
Proposal
@ -139,7 +139,7 @@ Note that ``$SOABI`` contains just the tag, while ``$EXT_SUFFIX`` 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 might see these files when the
For an arbitrary package ``foo``, you might see these files when the
distribution package was installed::
/usr/lib/python/foo.cpython-32m.so
@ -159,7 +159,7 @@ This shared library tag would be used globally for all distutils-based
extension modules, regardless of where on the file system they are
built. Extension modules built by means other than distutils would
either have to calculate the tag manually, or fallback to the
non-tagged `.so` file name.
non-tagged ``.so`` file name.
Proven approach
@ -170,7 +170,7 @@ and Ubuntu system where different extensions are used for debug builds
of Python and extension modules. Debug builds on Windows also already
use a different file extension for dynamic libraries, and in fact
encoded (in a different way than proposed in this PEP) the Python
major and minor version in the `.dll` file name.
major and minor version in the ``.dll`` file name.
Windows
@ -207,7 +207,7 @@ its name. The prefix ``abi`` is reserved for Python's use.
Thus, an initial implementation of :pep:`384`, when Python is configured
with the default set of flags, would search for the following file
names when extension module `foo` is imported (in this order)::
names when extension module ``foo`` is imported (in this order)::
foo.cpython-XYm.so
foo.abi3.so
@ -271,7 +271,7 @@ If a pure-Python package is shared in one version, should it suddenly
be not-shared if the next release adds an extension module for speed?
Also, even though all extension shared libraries will be compiled and
distributed once for every supported Python, there's a big difference
between duplicating the `.so` files and duplicating all `.py` files.
between duplicating the ``.so`` files and duplicating all ``.py`` files.
The extra size increases the download time for such packages, and more
immediately, increases the space pressures on already constrained
distribution CD-ROMs.