gh-110631: Fix some incorrect indents in the documentation (#129312)

This commit is contained in:
Yuki Kobayashi 2025-05-21 22:52:02 +09:00 committed by GitHub
parent 88f8102a8f
commit 15a8b5b9bd
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
4 changed files with 60 additions and 60 deletions

View file

@ -1154,44 +1154,44 @@ are always available. They are listed here in alphabetical order.
.. function:: locals()
Return a mapping object representing the current local symbol table, with
variable names as the keys, and their currently bound references as the
values.
Return a mapping object representing the current local symbol table, with
variable names as the keys, and their currently bound references as the
values.
At module scope, as well as when using :func:`exec` or :func:`eval` with
a single namespace, this function returns the same namespace as
:func:`globals`.
At module scope, as well as when using :func:`exec` or :func:`eval` with
a single namespace, this function returns the same namespace as
:func:`globals`.
At class scope, it returns the namespace that will be passed to the
metaclass constructor.
At class scope, it returns the namespace that will be passed to the
metaclass constructor.
When using ``exec()`` or ``eval()`` with separate local and global
arguments, it returns the local namespace passed in to the function call.
When using ``exec()`` or ``eval()`` with separate local and global
arguments, it returns the local namespace passed in to the function call.
In all of the above cases, each call to ``locals()`` in a given frame of
execution will return the *same* mapping object. Changes made through
the mapping object returned from ``locals()`` will be visible as assigned,
reassigned, or deleted local variables, and assigning, reassigning, or
deleting local variables will immediately affect the contents of the
returned mapping object.
In all of the above cases, each call to ``locals()`` in a given frame of
execution will return the *same* mapping object. Changes made through
the mapping object returned from ``locals()`` will be visible as assigned,
reassigned, or deleted local variables, and assigning, reassigning, or
deleting local variables will immediately affect the contents of the
returned mapping object.
In an :term:`optimized scope` (including functions, generators, and
coroutines), each call to ``locals()`` instead returns a fresh dictionary
containing the current bindings of the function's local variables and any
nonlocal cell references. In this case, name binding changes made via the
returned dict are *not* written back to the corresponding local variables
or nonlocal cell references, and assigning, reassigning, or deleting local
variables and nonlocal cell references does *not* affect the contents
of previously returned dictionaries.
In an :term:`optimized scope` (including functions, generators, and
coroutines), each call to ``locals()`` instead returns a fresh dictionary
containing the current bindings of the function's local variables and any
nonlocal cell references. In this case, name binding changes made via the
returned dict are *not* written back to the corresponding local variables
or nonlocal cell references, and assigning, reassigning, or deleting local
variables and nonlocal cell references does *not* affect the contents
of previously returned dictionaries.
Calling ``locals()`` as part of a comprehension in a function, generator, or
coroutine is equivalent to calling it in the containing scope, except that
the comprehension's initialised iteration variables will be included. In
other scopes, it behaves as if the comprehension were running as a nested
function.
Calling ``locals()`` as part of a comprehension in a function, generator, or
coroutine is equivalent to calling it in the containing scope, except that
the comprehension's initialised iteration variables will be included. In
other scopes, it behaves as if the comprehension were running as a nested
function.
Calling ``locals()`` as part of a generator expression is equivalent to
calling it in a nested generator function.
Calling ``locals()`` as part of a generator expression is equivalent to
calling it in a nested generator function.
.. versionchanged:: 3.12
The behaviour of ``locals()`` in a comprehension has been updated as

View file

@ -49,44 +49,44 @@
.. method:: open_resource(resource)
:abstractmethod:
Returns an opened, :term:`file-like object` for binary reading
of the *resource*.
Returns an opened, :term:`file-like object` for binary reading
of the *resource*.
If the resource cannot be found, :exc:`FileNotFoundError` is
raised.
If the resource cannot be found, :exc:`FileNotFoundError` is
raised.
.. method:: resource_path(resource)
:abstractmethod:
Returns the file system path to the *resource*.
Returns the file system path to the *resource*.
If the resource does not concretely exist on the file system,
raise :exc:`FileNotFoundError`.
If the resource does not concretely exist on the file system,
raise :exc:`FileNotFoundError`.
.. method:: is_resource(name)
:abstractmethod:
Returns ``True`` if the named *name* is considered a resource.
:exc:`FileNotFoundError` is raised if *name* does not exist.
Returns ``True`` if the named *name* is considered a resource.
:exc:`FileNotFoundError` is raised if *name* does not exist.
.. method:: contents()
:abstractmethod:
Returns an :term:`iterable` of strings over the contents of
the package. Do note that it is not required that all names
returned by the iterator be actual resources, e.g. it is
acceptable to return names for which :meth:`is_resource` would
be false.
Returns an :term:`iterable` of strings over the contents of
the package. Do note that it is not required that all names
returned by the iterator be actual resources, e.g. it is
acceptable to return names for which :meth:`is_resource` would
be false.
Allowing non-resource names to be returned is to allow for
situations where how a package and its resources are stored
are known a priori and the non-resource names would be useful.
For instance, returning subdirectory names is allowed so that
when it is known that the package and resources are stored on
the file system then those subdirectory names can be used
directly.
Allowing non-resource names to be returned is to allow for
situations where how a package and its resources are stored
are known a priori and the non-resource names would be useful.
For instance, returning subdirectory names is allowed so that
when it is known that the package and resources are stored on
the file system then those subdirectory names can be used
directly.
The abstract method returns an iterable of no items.
The abstract method returns an iterable of no items.
.. class:: Traversable

View file

@ -211,8 +211,8 @@ The variables defined in the :mod:`signal` module are:
.. data:: SIGSTKFLT
Stack fault on coprocessor. The Linux kernel does not raise this signal: it
can only be raised in user space.
Stack fault on coprocessor. The Linux kernel does not raise this signal: it
can only be raised in user space.
.. availability:: Linux.

View file

@ -362,10 +362,10 @@ Exceptions
Constants
^^^^^^^^^
The AF_* and SOCK_* constants are now :class:`AddressFamily` and
:class:`SocketKind` :class:`.IntEnum` collections.
The AF_* and SOCK_* constants are now :class:`AddressFamily` and
:class:`SocketKind` :class:`.IntEnum` collections.
.. versionadded:: 3.4
.. versionadded:: 3.4
.. data:: AF_UNIX
AF_INET
@ -773,9 +773,9 @@ Constants
Constant to optimize CPU locality, to be used in conjunction with
:data:`SO_REUSEPORT`.
.. versionadded:: 3.11
.. versionadded:: 3.11
.. availability:: Linux >= 3.9
.. availability:: Linux >= 3.9
.. data:: SO_REUSEPORT_LB