A few cosmetic fixes for PEP 451.
This commit is contained in:
Eric Snow
parent
d0c939ef39
commit
8cf5766d33
68
pep-0451.txt
68
pep-0451.txt
|
|
@ -96,7 +96,7 @@ The answer to this gap is a ``ModuleSpec`` object that contains the
|
|||
per-module information and takes care of the boilerplate functionality
|
||||
involved with loading the module.
|
||||
|
||||
(The idea gained momentum during discussions related to another PEP.[1])
|
||||
(The idea gained momentum during discussions related to another PEP.[1]_)
|
||||
|
||||
|
||||
Specification
|
||||
|
|
@ -116,18 +116,18 @@ importlib.machinery.ModuleSpec (new)
|
|||
|
||||
A specification for a module's import-system-related state.
|
||||
|
||||
* ModuleSpec(name, loader, \*, origin=None, loading_info=None, is_package=None)
|
||||
* ModuleSpec(name, loader, \*, origin=None, loader_state=None, is_package=None)
|
||||
|
||||
Attributes:
|
||||
|
||||
* name - a string for the name of the module.
|
||||
* loader - the loader to use for loading and for module data.
|
||||
* loader - the loader to use for loading.
|
||||
* origin - a string for the location from which the module is loaded,
|
||||
e.g. "builtin" for built-in modules and the filename for modules
|
||||
loaded from source.
|
||||
* submodule_search_locations - strings for where to find submodules,
|
||||
if a package.
|
||||
* loading_info - a container of extra data for use during loading.
|
||||
* submodule_search_locations - list of strings for where to find
|
||||
submodules, if a package (None otherwise).
|
||||
* loader_state - a container of extra data for use during loading.
|
||||
* cached (property) - a string for where the compiled module will be
|
||||
stored (see PEP 3147).
|
||||
* package (RO-property) - the name of the module's parent (or None).
|
||||
|
|
@ -161,10 +161,6 @@ Other API Additions
|
|||
* importlib.find_spec(name, path=None) will return the spec for a
|
||||
module.
|
||||
|
||||
exec_module() and create_module() should not set any import-related
|
||||
module attributes. The fact that load_module() does is a design flaw
|
||||
that this proposal aims to correct.
|
||||
|
||||
API Changes
|
||||
-----------
|
||||
|
||||
|
|
@ -201,7 +197,7 @@ Other Changes
|
|||
longer be used directly by the import system.
|
||||
* Import-related attributes should no longer be added to modules
|
||||
directly.
|
||||
* The module type's ``__repr__()`` will be thin wrapper around a pure
|
||||
* The module type's ``__repr__()`` will be a thin wrapper around a pure
|
||||
Python implementation which will leverage ModuleSpec.
|
||||
* The spec for the ``__main__`` module will reflect the appropriate
|
||||
name and origin.
|
||||
|
|
@ -254,7 +250,7 @@ uncommon cases the loader should also implement create_module().
|
|||
ModuleSpec Users
|
||||
================
|
||||
|
||||
``ModuleSpec`` objects has 3 distinct target audiences: Python itself,
|
||||
``ModuleSpec`` objects have 3 distinct target audiences: Python itself,
|
||||
import hooks, and normal Python users.
|
||||
|
||||
Python will use specs in the import machinery, in interpreter startup,
|
||||
|
|
@ -296,14 +292,12 @@ functionality::
|
|||
module = ModuleType(spec.name)
|
||||
spec.init_module_attrs(module)
|
||||
|
||||
spec._initializing = True
|
||||
sys.modues[spec.name] = module
|
||||
try:
|
||||
spec.loader.exec_module(module)
|
||||
except Exception:
|
||||
del sys.modules[spec.name]
|
||||
finally:
|
||||
spec._initializing = False
|
||||
raise
|
||||
return sys.modules[spec.name]
|
||||
|
||||
These steps are exactly what ``Loader.load_module()`` is already
|
||||
|
|
@ -340,12 +334,12 @@ package __package__
|
|||
origin __file__*
|
||||
cached __cached__*,**
|
||||
submodule_search_locations __path__**
|
||||
loading_info \-
|
||||
loader_state \-
|
||||
has_location \-
|
||||
========================== ==============
|
||||
|
||||
\* Set only if has_location is true.
|
||||
\*\* Set only if the spec attribute is not None.
|
||||
\* Set on the module only if spec.has_location is true.
|
||||
\*\* Set on the module only if the spec attribute is not None.
|
||||
|
||||
While package and has_location are read-only properties, the remaining
|
||||
attributes can be replaced after the module spec is created and even
|
||||
|
|
@ -381,10 +375,10 @@ set on the module. Not all locatable modules will be cachable, but most
|
|||
will.
|
||||
|
||||
The corresponding module attribute name, ``__file__``, is somewhat
|
||||
inaccurate and potentially confusion, so we will use a more explicit
|
||||
inaccurate and potentially confusing, so we will use a more explicit
|
||||
combination of origin and has_location to represent the same
|
||||
information. Having a separate filename is unncessary since we have
|
||||
origin.
|
||||
information. Having a separate "filename" is unncessary since we have
|
||||
"origin".
|
||||
|
||||
**submodule_search_locations**
|
||||
|
||||
|
|
@ -396,9 +390,9 @@ The corresponding module attribute's name, ``__path__``, is relatively
|
|||
ambiguous. Instead of mirroring it, we use a more explicit name that
|
||||
makes the purpose clear.
|
||||
|
||||
**loading_info**
|
||||
**loader_state**
|
||||
|
||||
A finder may set loading_info to any value to provide additional
|
||||
A finder may set loader_state to any value to provide additional
|
||||
data for the loader to use during loading. A value of None is the
|
||||
default and indicates that there is no additional data. Otherwise it
|
||||
can be set to any object, such as a dict, list, or
|
||||
|
|
@ -408,7 +402,7 @@ For example, zipimporter could use it to pass the zip archive name
|
|||
to the loader directly, rather than needing to derive it from origin
|
||||
or create a custom loader for each find operation.
|
||||
|
||||
loading_info is meant for use by the finder and corresponding loader.
|
||||
loader_state is meant for use by the finder and corresponding loader.
|
||||
It is not guaranteed to be a stable resource for any other use.
|
||||
|
||||
Omitted Attributes and Methods
|
||||
|
|
@ -418,10 +412,10 @@ The following ModuleSpec methods are not part of the public API since
|
|||
it is easy to use them incorrectly and only the import system really
|
||||
needs them (i.e. they would be an attractive nuisance).
|
||||
|
||||
* create() - provide a new module to use for loading.
|
||||
* exec(module) - execute the spec into a module namespace.
|
||||
* load() - prepare a module and execute it in a protected way.
|
||||
* reload(module) - re-execute a module in a protected way.
|
||||
* _create() - provide a new module to use for loading.
|
||||
* _exec(module) - execute the spec into a module namespace.
|
||||
* _load() - prepare a module and execute it in a protected way.
|
||||
* _reload(module) - re-execute a module in a protected way.
|
||||
|
||||
Here are other omissions:
|
||||
|
||||
|
|
@ -468,7 +462,7 @@ Subclassing
|
|||
-----------
|
||||
|
||||
Subclasses of ModuleSpec are allowed, but should not be necessary.
|
||||
Simply setting loading_info or adding functionality to a custom
|
||||
Simply setting loader_state or adding functionality to a custom
|
||||
finder or loader will likely be a better fit and should be tried first.
|
||||
However, as long as a subclass still fulfills the requirements of the
|
||||
import system, objects of that type are completely fine as the return
|
||||
|
|
@ -552,6 +546,12 @@ create_module() should properly handle the case where it is called more
|
|||
than once for the same spec/module. This may include returning None or
|
||||
raising ImportError.
|
||||
|
||||
.. note::
|
||||
|
||||
exec_module() and create_module() should not set any import-related
|
||||
module attributes. The fact that load_module() does is a design flaw
|
||||
that this proposal aims to correct.
|
||||
|
||||
Other changes:
|
||||
|
||||
PEP 420 introduced the optional ``module_repr()`` loader method to limit
|
||||
|
|
@ -614,15 +614,9 @@ inspect.
|
|||
For instance, pickle should be updated in the __main__ case to look at
|
||||
``module.__spec__.name``.
|
||||
|
||||
\* Impact on some kinds of lazy loading modules. See [3].
|
||||
\* Add broader reloading support? See [2]_.
|
||||
|
||||
\* Find a better name than loading_info? Perhaps loading_data,
|
||||
loader_state, or loader_info.
|
||||
|
||||
\* Change loader.create_module() to prepare_module()?
|
||||
|
||||
\* Add more explicit reloading support to exec_module() (and
|
||||
prepare_module())?
|
||||
\* Impact on some kinds of lazy loading modules. See [3]_.
|
||||
|
||||
|
||||
References
|
||||
|
|
|
|||
Loading…
Reference in New Issue