diff options
author | Stéphane Wirtel <stephane@wirtel.be> | 2018-10-26 22:58:26 (GMT) |
---|---|---|
committer | Brett Cannon <brettcannon@users.noreply.github.com> | 2018-10-26 22:58:26 (GMT) |
commit | 12e696b4f071ffe0d585b7f0d0d8020fd328bfdd (patch) | |
tree | 81ff44e5896a18441710a3e8f24543bf4d9382f5 /Doc/whatsnew | |
parent | 9e14e49f13ef1a726f31efe6689285463332db6e (diff) | |
download | cpython-12e696b4f071ffe0d585b7f0d0d8020fd328bfdd.zip cpython-12e696b4f071ffe0d585b7f0d0d8020fd328bfdd.tar.gz cpython-12e696b4f071ffe0d585b7f0d0d8020fd328bfdd.tar.bz2 |
bpo-35042: Use the :pep: role where a PEP is specified (#10036)
Diffstat (limited to 'Doc/whatsnew')
-rw-r--r-- | Doc/whatsnew/2.0.rst | 6 | ||||
-rw-r--r-- | Doc/whatsnew/2.1.rst | 10 | ||||
-rw-r--r-- | Doc/whatsnew/2.5.rst | 8 | ||||
-rw-r--r-- | Doc/whatsnew/3.3.rst | 8 |
4 files changed, 16 insertions, 16 deletions
diff --git a/Doc/whatsnew/2.0.rst b/Doc/whatsnew/2.0.rst index 5cbf501..8c740ee 100644 --- a/Doc/whatsnew/2.0.rst +++ b/Doc/whatsnew/2.0.rst @@ -111,7 +111,7 @@ python-dev. Therefore, a relatively formal process has been set up to write Python Enhancement Proposals (PEPs), modelled on the Internet RFC process. PEPs are draft documents that describe a proposed new feature, and are continually revised until the community reaches a consensus, either accepting or rejecting -the proposal. Quoting from the introduction to PEP 1, "PEP Purpose and +the proposal. Quoting from the introduction to :pep:`1`, "PEP Purpose and Guidelines": @@ -127,11 +127,11 @@ Guidelines": that have gone into Python. The PEP author is responsible for building consensus within the community and documenting dissenting opinions. -Read the rest of PEP 1 for the details of the PEP editorial process, style, and +Read the rest of :pep:`1` for the details of the PEP editorial process, style, and format. PEPs are kept in the Python CVS tree on SourceForge, though they're not part of the Python 2.0 distribution, and are also available in HTML form from https://www.python.org/dev/peps/. As of September 2000, there are 25 PEPS, ranging -from PEP 201, "Lockstep Iteration", to PEP 225, "Elementwise/Objectwise +from :pep:`201`, "Lockstep Iteration", to PEP 225, "Elementwise/Objectwise Operators". .. ====================================================================== diff --git a/Doc/whatsnew/2.1.rst b/Doc/whatsnew/2.1.rst index 3486cdd..12c028f 100644 --- a/Doc/whatsnew/2.1.rst +++ b/Doc/whatsnew/2.1.rst @@ -112,8 +112,8 @@ anyway). Compatibility concerns have led to nested scopes being introduced gradually; in Python 2.1, they aren't enabled by default, but can be turned on within a module -by using a future statement as described in PEP 236. (See the following section -for further discussion of PEP 236.) In Python 2.2, nested scopes will become +by using a future statement as described in :pep:`236`. (See the following section +for further discussion of :pep:`236`.) In Python 2.2, nested scopes will become the default and there will be no way to turn them off, but users will have had all of 2.1's lifetime to fix any breakage resulting from their introduction. @@ -213,7 +213,7 @@ otherwise it will call the appropriate method and can return any Python object. There are also corresponding changes of interest to C programmers; there's a new slot ``tp_richcmp`` in type objects and an API for performing a given rich -comparison. I won't cover the C API here, but will refer you to PEP 207, or to +comparison. I won't cover the C API here, but will refer you to :pep:`207`, or to 2.1's C API documentation, for the full list of related functions. @@ -548,7 +548,7 @@ registering software at the Vaults is optional, and many people don't bother. As a first small step toward fixing the problem, Python software packaged using the Distutils :command:`sdist` command will include a file named :file:`PKG-INFO` containing information about the package such as its name, -version, and author (metadata, in cataloguing terminology). PEP 241 contains +version, and author (metadata, in cataloguing terminology). :pep:`241` contains the full list of fields that can be present in the :file:`PKG-INFO` file. As people began to package their software using Python 2.1, more and more packages will include metadata, making it possible to build automated cataloguing systems @@ -561,7 +561,7 @@ package to a catalog server. You can start creating packages containing :file:`PKG-INFO` even if you're not using Python 2.1, since a new release of the Distutils will be made for users of earlier Python versions. Version 1.0.2 of the Distutils includes the changes -described in PEP 241, as well as various bugfixes and enhancements. It will be +described in :pep:`241`, as well as various bugfixes and enhancements. It will be available from the Distutils SIG at https://www.python.org/community/sigs/current/distutils-sig/. diff --git a/Doc/whatsnew/2.5.rst b/Doc/whatsnew/2.5.rst index 79c5a73..d70b642 100644 --- a/Doc/whatsnew/2.5.rst +++ b/Doc/whatsnew/2.5.rst @@ -256,7 +256,7 @@ Package uploading was implemented by Martin von Löwis and Richard Jones. PEP 328: Absolute and Relative Imports ====================================== -The simpler part of PEP 328 was implemented in Python 2.4: parentheses could now +The simpler part of :pep:`328` was implemented in Python 2.4: parentheses could now be used to enclose the names imported from a module using the ``from ... import ...`` statement, making it easier to import many different names. @@ -529,7 +529,7 @@ chance to run. The syntactic restriction that you couldn't mix :keyword:`yield` statements with a ``try...finally`` suite has therefore been removed. This seems like a minor bit of language trivia, but using generators and ``try...finally`` is actually necessary in order to implement the -:keyword:`with` statement described by PEP 343. I'll look at this new statement +:keyword:`with` statement described by :pep:`343`. I'll look at this new statement in the following section. Another even more esoteric effect of this change: previously, the @@ -1483,7 +1483,7 @@ complete list of changes, or look through the SVN logs for all the details. 2.4, so this completes the removal of the feature. * The :mod:`pkgutil` module, containing various utility functions for finding - packages, was enhanced to support PEP 302's import hooks and now also works for + packages, was enhanced to support :pep:`302`'s import hooks and now also works for packages stored in ZIP-format archives. (Contributed by Phillip J. Eby.) * The pybench benchmark suite by Marc-André Lemburg is now included in the @@ -2043,7 +2043,7 @@ between web servers and Python web applications and is described in :pep:`333`. The :mod:`wsgiref` package is a reference implementation of the WSGI specification. -.. XXX should this be in a PEP 333 section instead? +.. XXX should this be in a :pep:`333` section instead? The package includes a basic HTTP server that will run a WSGI application; this server is useful for debugging but isn't intended for production use. Setting diff --git a/Doc/whatsnew/3.3.rst b/Doc/whatsnew/3.3.rst index 8862b37..ea03684 100644 --- a/Doc/whatsnew/3.3.rst +++ b/Doc/whatsnew/3.3.rst @@ -217,7 +217,7 @@ exist in parallel; over time, this compatibility should be phased out. On the Python side, there should be no downside to this change. -On the C API side, PEP 393 is fully backward compatible. The legacy API +On the C API side, :pep:`393` is fully backward compatible. The legacy API should remain available at least five years. Applications using the legacy API will not fully benefit of the memory reduction, or - worse - may use a bit more memory, because Python may have to maintain two versions of each @@ -2082,7 +2082,7 @@ Add a new :class:`types.MappingProxyType` class: Read-only proxy of a mapping. The new functions :func:`types.new_class` and :func:`types.prepare_class` provide support -for PEP 3115 compliant dynamic type creation. (:issue:`14588`) +for :pep:`3115` compliant dynamic type creation. (:issue:`14588`) unittest @@ -2396,7 +2396,7 @@ Porting Python code case of working with :term:`path entry finders <path entry finder>`. * :mod:`pkgutil` has been converted to use :mod:`importlib` internally. This - eliminates many edge cases where the old behaviour of the PEP 302 import + eliminates many edge cases where the old behaviour of the :pep:`302` import emulation failed to match the behaviour of the real import system. The import emulation itself is still present, but is now deprecated. The :func:`pkgutil.iter_importers` and :func:`pkgutil.walk_packages` functions @@ -2472,7 +2472,7 @@ Porting C code functions using this type are deprecated (but will stay available for at least five years). If you were using low-level Unicode APIs to construct and access unicode objects and you want to benefit of the - memory footprint reduction provided by PEP 393, you have to convert + memory footprint reduction provided by :pep:`393`, you have to convert your code to the new :doc:`Unicode API <../c-api/unicode>`. However, if you only have been using high-level functions such as |