mirrors/cpython
1
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2025-08-10 03:49:18 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 10

[3.12] gh-110631: Fix reST indentation in Doc/reference (GH-110708) (#110740)

Browse source 
gh-110631: Fix reST indentation in `Doc/reference` (GH-110708)

Fix wrong indentation in the Doc/reference dir.
(cherry picked from commit 41d8ec5a1b)

Co-authored-by: Ezio Melotti <ezio.melotti@gmail.com>
This commit is contained in:
Miss Islington (bot) 2023-10-11 23:13:21 +02:00 • committed by GitHub
parent 7d5a982609
commit dbbe0eebf0
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
4 changed files with 79 additions and 77 deletions
Download patch file Download diff file Expand all files Collapse all files

48
Doc/reference/compound_stmts.rst
View file

@ -642,14 +642,14 @@ Here's an overview of the logical flow of a match statement:
specified below. **Name bindings made during a successful pattern match
outlive the executed block and can be used after the match statement**.
.. note::
.. note::
During failed pattern matches, some subpatterns may succeed. Do not
rely on bindings being made for a failed match. Conversely, do not
rely on variables remaining unchanged after a failed match. The exact
behavior is dependent on implementation and may vary. This is an
intentional decision made to allow different implementations to add
optimizations.
During failed pattern matches, some subpatterns may succeed. Do not
rely on bindings being made for a failed match. Conversely, do not
rely on variables remaining unchanged after a failed match. The exact
behavior is dependent on implementation and may vary. This is an
intentional decision made to allow different implementations to add
optimizations.
#. If the pattern succeeds, the corresponding guard (if present) is evaluated. In
this case all name bindings are guaranteed to have happened.
@ -1170,8 +1170,10 @@ In simple terms ``CLS(P1, attr=P2)`` matches only if the following happens:
* ``isinstance(<subject>, CLS)``
* convert ``P1`` to a keyword pattern using ``CLS.__match_args__``
* For each keyword argument ``attr=P2``:
* ``hasattr(<subject>, "attr")``
* ``P2`` matches ``<subject>.attr``
* ``hasattr(<subject>, "attr")``
* ``P2`` matches ``<subject>.attr``
* ... and so on for the corresponding keyword argument/pattern pair.
.. seealso::
@ -1838,29 +1840,29 @@ like ``TYPE_PARAMS_OF_ListOrSet`` are not actually bound at runtime.
.. [#] In pattern matching, a sequence is defined as one of the following:
* a class that inherits from :class:`collections.abc.Sequence`
* a Python class that has been registered as :class:`collections.abc.Sequence`
* a builtin class that has its (CPython) :c:macro:`Py_TPFLAGS_SEQUENCE` bit set
* a class that inherits from any of the above
* a class that inherits from :class:`collections.abc.Sequence`
* a Python class that has been registered as :class:`collections.abc.Sequence`
* a builtin class that has its (CPython) :c:macro:`Py_TPFLAGS_SEQUENCE` bit set
* a class that inherits from any of the above
The following standard library classes are sequences:
* :class:`array.array`
* :class:`collections.deque`
* :class:`list`
* :class:`memoryview`
* :class:`range`
* :class:`tuple`
* :class:`array.array`
* :class:`collections.deque`
* :class:`list`
* :class:`memoryview`
* :class:`range`
* :class:`tuple`
.. note:: Subject values of type ``str``, ``bytes``, and ``bytearray``
do not match sequence patterns.
.. [#] In pattern matching, a mapping is defined as one of the following:
* a class that inherits from :class:`collections.abc.Mapping`
* a Python class that has been registered as :class:`collections.abc.Mapping`
* a builtin class that has its (CPython) :c:macro:`Py_TPFLAGS_MAPPING` bit set
* a class that inherits from any of the above
* a class that inherits from :class:`collections.abc.Mapping`
* a Python class that has been registered as :class:`collections.abc.Mapping`
* a builtin class that has its (CPython) :c:macro:`Py_TPFLAGS_MAPPING` bit set
* a class that inherits from any of the above
The standard library classes :class:`dict` and :class:`types.MappingProxyType`
are mappings.

4
Doc/reference/expressions.rst
View file

@ -499,8 +499,8 @@ the yield expression. It can be either set explicitly when raising
:exc:`StopIteration`, or automatically when the subiterator is a generator
(by returning a value from the subgenerator).
.. versionchanged:: 3.3
Added ``yield from <expr>`` to delegate control flow to a subiterator.
.. versionchanged:: 3.3
Added ``yield from <expr>`` to delegate control flow to a subiterator.
The parentheses may be omitted when the yield expression is the sole expression
on the right hand side of an assignment statement.

94
Doc/reference/import.rst
View file

@ -375,32 +375,32 @@ of what happens during the loading portion of import::
Note the following details:
* If there is an existing module object with the given name in
:data:`sys.modules`, import will have already returned it.
* If there is an existing module object with the given name in
:data:`sys.modules`, import will have already returned it.
* The module will exist in :data:`sys.modules` before the loader
executes the module code. This is crucial because the module code may
(directly or indirectly) import itself; adding it to :data:`sys.modules`
beforehand prevents unbounded recursion in the worst case and multiple
loading in the best.
* The module will exist in :data:`sys.modules` before the loader
executes the module code. This is crucial because the module code may
(directly or indirectly) import itself; adding it to :data:`sys.modules`
beforehand prevents unbounded recursion in the worst case and multiple
loading in the best.
* If loading fails, the failing module -- and only the failing module --
gets removed from :data:`sys.modules`. Any module already in the
:data:`sys.modules` cache, and any module that was successfully loaded
as a side-effect, must remain in the cache. This contrasts with
reloading where even the failing module is left in :data:`sys.modules`.
* If loading fails, the failing module -- and only the failing module --
gets removed from :data:`sys.modules`. Any module already in the
:data:`sys.modules` cache, and any module that was successfully loaded
as a side-effect, must remain in the cache. This contrasts with
reloading where even the failing module is left in :data:`sys.modules`.
* After the module is created but before execution, the import machinery
sets the import-related module attributes ("_init_module_attrs" in
the pseudo-code example above), as summarized in a
:ref:`later section <import-mod-attrs>`.
* After the module is created but before execution, the import machinery
sets the import-related module attributes ("_init_module_attrs" in
the pseudo-code example above), as summarized in a
:ref:`later section <import-mod-attrs>`.
* Module execution is the key moment of loading in which the module's
namespace gets populated. Execution is entirely delegated to the
loader, which gets to decide what gets populated and how.
* Module execution is the key moment of loading in which the module's
namespace gets populated. Execution is entirely delegated to the
loader, which gets to decide what gets populated and how.
* The module created during loading and passed to exec_module() may
not be the one returned at the end of import [#fnlo]_.
* The module created during loading and passed to exec_module() may
not be the one returned at the end of import [#fnlo]_.
.. versionchanged:: 3.4
The import system has taken over the boilerplate responsibilities of
@ -417,13 +417,13 @@ returned from :meth:`~importlib.abc.Loader.exec_module` is ignored.
Loaders must satisfy the following requirements:
* If the module is a Python module (as opposed to a built-in module or a
dynamically loaded extension), the loader should execute the module's code
in the module's global name space (``module.__dict__``).
* If the module is a Python module (as opposed to a built-in module or a
dynamically loaded extension), the loader should execute the module's code
in the module's global name space (``module.__dict__``).
* If the loader cannot execute the module, it should raise an
:exc:`ImportError`, although any other exception raised during
:meth:`~importlib.abc.Loader.exec_module` will be propagated.
* If the loader cannot execute the module, it should raise an
:exc:`ImportError`, although any other exception raised during
:meth:`~importlib.abc.Loader.exec_module` will be propagated.
In many cases, the finder and loader can be the same object; in such cases the
:meth:`~importlib.abc.MetaPathFinder.find_spec` method would just return a
@ -453,20 +453,20 @@ import machinery will create the new module itself.
functionality described above in addition to executing the module. All
the same constraints apply, with some additional clarification:
* If there is an existing module object with the given name in
:data:`sys.modules`, the loader must use that existing module.
(Otherwise, :func:`importlib.reload` will not work correctly.) If the
named module does not exist in :data:`sys.modules`, the loader
must create a new module object and add it to :data:`sys.modules`.
* If there is an existing module object with the given name in
:data:`sys.modules`, the loader must use that existing module.
(Otherwise, :func:`importlib.reload` will not work correctly.) If the
named module does not exist in :data:`sys.modules`, the loader
must create a new module object and add it to :data:`sys.modules`.
* The module *must* exist in :data:`sys.modules` before the loader
executes the module code, to prevent unbounded recursion or multiple
loading.
* The module *must* exist in :data:`sys.modules` before the loader
executes the module code, to prevent unbounded recursion or multiple
loading.
* If loading fails, the loader must remove any modules it has inserted
into :data:`sys.modules`, but it must remove **only** the failing
module(s), and only if the loader itself has loaded the module(s)
explicitly.
* If loading fails, the loader must remove any modules it has inserted
into :data:`sys.modules`, but it must remove **only** the failing
module(s), and only if the loader itself has loaded the module(s)
explicitly.
.. versionchanged:: 3.5
A :exc:`DeprecationWarning` is raised when ``exec_module()`` is defined but
@ -693,17 +693,17 @@ with defaults for whatever information is missing.
Here are the exact rules used:
* If the module has a ``__spec__`` attribute, the information in the spec
is used to generate the repr. The "name", "loader", "origin", and
"has_location" attributes are consulted.
* If the module has a ``__spec__`` attribute, the information in the spec
is used to generate the repr. The "name", "loader", "origin", and
"has_location" attributes are consulted.
* If the module has a ``__file__`` attribute, this is used as part of the
module's repr.
* If the module has a ``__file__`` attribute, this is used as part of the
module's repr.
* If the module has no ``__file__`` but does have a ``__loader__`` that is not
``None``, then the loader's repr is used as part of the module's repr.
* If the module has no ``__file__`` but does have a ``__loader__`` that is not
``None``, then the loader's repr is used as part of the module's repr.
* Otherwise, just use the module's ``__name__`` in the repr.
* Otherwise, just use the module's ``__name__`` in the repr.
.. versionchanged:: 3.12
Use of :meth:`!module_repr`, having been deprecated since Python 3.4, was

10
Doc/reference/lexical_analysis.rst
View file

@ -657,12 +657,12 @@ is more easily recognized as broken.) It is also important to note that the
escape sequences only recognized in string literals fall into the category of
unrecognized escapes for bytes literals.
.. versionchanged:: 3.6
Unrecognized escape sequences produce a :exc:`DeprecationWarning`.
.. versionchanged:: 3.6
Unrecognized escape sequences produce a :exc:`DeprecationWarning`.
.. versionchanged:: 3.12
Unrecognized escape sequences produce a :exc:`SyntaxWarning`. In a future
Python version they will be eventually a :exc:`SyntaxError`.
.. versionchanged:: 3.12
Unrecognized escape sequences produce a :exc:`SyntaxWarning`. In a future
Python version they will be eventually a :exc:`SyntaxError`.
Even in a raw literal, quotes can be escaped with a backslash, but the
backslash remains in the result; for example, ``r"\""`` is a valid string