pythongh-110631: Fix reST indentation in Doc/reference (python#110708)

Fix wrong indentation in the Doc/reference dir.

Doc/reference/compound_stmts.rst

@@ -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.

Doc/reference/expressions.rst

@@ -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.

Doc/reference/import.rst

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

Doc/reference/lexical_analysis.rst

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