.. 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.
-
- 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.
-
- 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 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 generator expression is equivalent to
- calling it in a nested generator function.
+ 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 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.
+
+ 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.
+
+ 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.
.. versionchanged:: 3.12
The behaviour of ``locals()`` in a comprehension has been updated as
.. 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.
-
- 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.
+ 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.
+
+ The abstract method returns an iterable of no items.
.. class:: Traversable
projects / thirdparty / Python / cpython.git / commitdiff
