[Python-checkins] peps: A few cosmetic fixes for PEP 451.
eric.snow
python-checkins at python.org
Thu Sep 19 07:07:28 CEST 2013
http://hg.python.org/peps/rev/d9626c2b66da
changeset: 5132:d9626c2b66da
user: Eric Snow <ericsnowcurrently at gmail.com>
date: Wed Sep 18 23:04:47 2013 -0600
summary:
A few cosmetic fixes for PEP 451.
files:
pep-0451.txt | 68 ++++++++++++++++++---------------------
1 files changed, 31 insertions(+), 37 deletions(-)
diff --git a/pep-0451.txt b/pep-0451.txt
--- a/pep-0451.txt
+++ b/pep-0451.txt
@@ -96,7 +96,7 @@
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 @@
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 @@
* 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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
-----------
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 @@
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 @@
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
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list