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.
* ``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::
.. [#] 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.
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
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
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
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
projects / thirdparty / Python / cpython.git / commitdiff
