PEP 425: Resolve uses of the default role (#3393)
This commit is contained in:
parent
c8346db3e6
commit
fba94ce6c9
42
pep-0425.txt
42
pep-0425.txt
|
@ -71,7 +71,7 @@ For example, the tag py27-none-any indicates compatible with Python 2.7
|
|||
Use
|
||||
===
|
||||
|
||||
The `wheel` built package format includes these tags in its filenames,
|
||||
The ``wheel`` built package format includes these tags in its filenames,
|
||||
of the form ``{distribution}-{version}(-{build tag})?-{python tag}-{abi
|
||||
tag}-{platform tag}.whl``. Other package formats may have their own
|
||||
conventions.
|
||||
|
@ -91,31 +91,31 @@ a distribution. Major implementations have abbreviated codes, initially:
|
|||
* pp: PyPy
|
||||
* jy: Jython
|
||||
|
||||
Other Python implementations should use `sys.implementation.name`.
|
||||
Other Python implementations should use ``sys.implementation.name``.
|
||||
|
||||
The version is `py_version_nodot`. CPython gets away with no dot,
|
||||
but if one is needed the underscore `_` is used instead. PyPy should
|
||||
probably use its own versions here `pp18`, `pp19`.
|
||||
The version is ``py_version_nodot``. CPython gets away with no dot,
|
||||
but if one is needed the underscore ``_`` is used instead. PyPy should
|
||||
probably use its own versions here ``pp18``, ``pp19``.
|
||||
|
||||
The version can be just the major version `2` or `3` `py2`, `py3` for
|
||||
The version can be just the major version ``2`` or ``3`` ``py2``, ``py3`` for
|
||||
many pure-Python distributions.
|
||||
|
||||
Importantly, major-version-only tags like `py2` and `py3` are not
|
||||
shorthand for `py20` and `py30`. Instead, these tags mean the packager
|
||||
Importantly, major-version-only tags like ``py2`` and ``py3`` are not
|
||||
shorthand for ``py20`` and ``py30``. Instead, these tags mean the packager
|
||||
intentionally released a cross-version-compatible distribution.
|
||||
|
||||
A single-source Python 2/3 compatible distribution can use the compound
|
||||
tag `py2.py3`. See `Compressed Tag Sets`, below.
|
||||
tag ``py2.py3``. See ``Compressed Tag Sets``, below.
|
||||
|
||||
ABI Tag
|
||||
-------
|
||||
|
||||
The ABI tag indicates which Python ABI is required by any included
|
||||
extension modules. For implementation-specific ABIs, the implementation
|
||||
is abbreviated in the same way as the Python Tag, e.g. `cp33d` would be
|
||||
is abbreviated in the same way as the Python Tag, e.g. ``cp33d`` would be
|
||||
the CPython 3.3 ABI with debugging.
|
||||
|
||||
The CPython stable ABI is `abi3` as in the shared library suffix.
|
||||
The CPython stable ABI is ``abi3`` as in the shared library suffix.
|
||||
|
||||
Implementations with a very unstable ABI may use the first 6 bytes (as
|
||||
8 base64-encoded characters) of the SHA-256 hash of their source code
|
||||
|
@ -126,8 +126,8 @@ decide how to best use the ABI tag.
|
|||
Platform Tag
|
||||
------------
|
||||
|
||||
The platform tag is simply `distutils.util.get_platform()` with all
|
||||
hyphens `-` and periods `.` replaced with underscore `_`.
|
||||
The platform tag is simply ``distutils.util.get_platform()`` with all
|
||||
hyphens ``-`` and periods ``.`` replaced with underscore ``_``.
|
||||
|
||||
* win32
|
||||
* linux_i386
|
||||
|
@ -139,7 +139,7 @@ Use
|
|||
The tags are used by installers to decide which built distribution
|
||||
(if any) to download from a list of potential built distributions.
|
||||
The installer maintains a list of (pyver, abi, arch) tuples that it
|
||||
will support. If the built distribution's tag is `in` the list, then
|
||||
will support. If the built distribution's tag is ``in`` the list, then
|
||||
it can be installed.
|
||||
|
||||
It is recommended that installers try to choose the most feature complete
|
||||
|
@ -147,7 +147,7 @@ built distribution available (the one most specific to the installation
|
|||
environment) by default before falling back to pure Python versions
|
||||
published for older Python releases. Installers are also recommended to
|
||||
provide a way to configure and re-order the list of allowed compatibility
|
||||
tags; for example, a user might accept only the `*-none-any` tags to only
|
||||
tags; for example, a user might accept only the ``*-none-any`` tags to only
|
||||
download built packages that advertise themselves as being pure Python.
|
||||
|
||||
Another desirable installer feature might be to include "re-compile from
|
||||
|
@ -181,8 +181,8 @@ older version of Python):
|
|||
|
||||
Sometimes there will be more than one supported built distribution for a
|
||||
particular version of a package. For example, a packager could release
|
||||
a package tagged `cp33-abi3-linux_x86_64` that contains an optional C
|
||||
extension and the same distribution tagged `py3-none-any` that does not.
|
||||
a package tagged ``cp33-abi3-linux_x86_64`` that contains an optional C
|
||||
extension and the same distribution tagged ``py3-none-any`` that does not.
|
||||
The index of the tag in the supported tags list breaks the tie, and the
|
||||
package with the C extension is installed in preference to the package
|
||||
without because that tag appears first in the list.
|
||||
|
@ -194,7 +194,7 @@ To allow for compact filenames of bdists that work with more than
|
|||
one compatibility tag triple, each tag in a filename can instead be a
|
||||
'.'-separated, sorted, set of tags. For example, pip, a pure-Python
|
||||
package that is written to run under Python 2 and 3 with the same source
|
||||
code, could distribute a bdist with the tag `py2.py3-none-any`.
|
||||
code, could distribute a bdist with the tag ``py2.py3-none-any``.
|
||||
The full list of simple tags is::
|
||||
|
||||
for x in pytag.split('.'):
|
||||
|
@ -212,8 +212,8 @@ FAQ
|
|||
|
||||
What tags are used by default?
|
||||
Tools should use the most-preferred architecture dependent tag
|
||||
e.g. `cp33-cp33m-win32` or the most-preferred pure python tag
|
||||
e.g. `py33-none-any` by default. If the packager overrides the
|
||||
e.g. ``cp33-cp33m-win32`` or the most-preferred pure python tag
|
||||
e.g. ``py33-none-any`` by default. If the packager overrides the
|
||||
default it indicates that they intended to provide cross-Python
|
||||
compatibility.
|
||||
|
||||
|
@ -227,7 +227,7 @@ What tag do I use if my distribution uses a feature exclusive to the newest vers
|
|||
older release ``beaglevote-1.1.0`` that does not use the new feature,
|
||||
to get a compatible build.
|
||||
|
||||
Why isn't there a `.` in the Python version number?
|
||||
Why isn't there a ``.`` in the Python version number?
|
||||
CPython has lasted 20+ years without a 3-digit major release. This
|
||||
should continue for some time. Other implementations may use _ as
|
||||
a delimiter, since both - and . delimit the surrounding filename.
|
||||
|
|
Loading…
Reference in New Issue