[Python-checkins] peps: [PEP 451] Minor edits in response to feedback.
eric.snow
python-checkins at python.org
Wed Oct 2 06:11:08 CEST 2013
http://hg.python.org/peps/rev/39b84a006067
changeset: 5159:39b84a006067
user: Eric Snow <ericsnowcurrently at gmail.com>
date: Tue Oct 01 22:07:46 2013 -0600
summary:
[PEP 451] Minor edits in response to feedback.
Also removed spec_from_module(), which isn't very useful outside the
import system.
files:
pep-0451.txt | 43 ++++++++++++++-------------------------
1 files changed, 16 insertions(+), 27 deletions(-)
diff --git a/pep-0451.txt b/pep-0451.txt
--- a/pep-0451.txt
+++ b/pep-0451.txt
@@ -9,7 +9,7 @@
Content-Type: text/x-rst
Created: 8-Aug-2013
Python-Version: 3.4
-Post-History: 8-Aug-2013, 28-Aug-2013, 18-Sep-2013
+Post-History: 8-Aug-2013, 28-Aug-2013, 18-Sep-2013, 24-Sep-2013
Resolution:
@@ -58,7 +58,7 @@
module.
Right now loaders (via load_module()) are responsible for certain
-boilerplate import-related operations. These are:
+boilerplate, import-related operations. These are:
1. perform some (module-related) validation;
2. create the module object;
@@ -76,7 +76,7 @@
This is a new term and concept. The idea of it exists subtly in the
import system already, but this proposal makes the concept explicit.
-"origin" is the import context means the system (or resource within a
+"origin" in an import context means the system (or resource within a
system) from which a module originates. For the purposes of this
proposal, "origin" is also a string which identifies such a resource or
system. "origin" is applicable to all modules.
@@ -133,7 +133,8 @@
``__cache__`` attribute of modules and the cache_from_source() function
in importlib.util. Loaders are responsible for putting modules into the
cache (and loading out of the cache). Currently the cache is only used
-for compiled source modules. However, this proposal explicitly allows
+for compiled source modules. However, loaders may take advantage of
+the module cache for other kinds of modules.
package
-------
@@ -141,7 +142,7 @@
The concept does not change, nor does the term. However, the
distinction between modules and packages is mostly superficial.
Packages *are* modules. They simply have a ``__path__`` attribute and
-import may add attributes bound to submodules. The typical perceived
+import may add attributes bound to submodules. The typically perceived
difference is a source of confusion. This proposal explicitly
de-emphasizes the distinction between packages and modules where it
makes sense to do so.
@@ -273,12 +274,6 @@
* from_loader(name, loader, \*, origin=None, is_package=None) - build
a spec with missing information filled in by using loader APIs.
-This factory function is useful for some backward-compatibility
-situations:
-
-* spec_from_module(module, loader=None) - build a spec based on the
- import-related attributes of an existing module.
-
Other API Additions
-------------------
@@ -332,10 +327,12 @@
* The import system implementation in importlib will be changed to make
use of ModuleSpec.
* importlib.reload() will make use of ModuleSpec.
-* Import-related module attributes (other than ``__spec__``) will no
- longer be used directly by the import system.
+* A module's import-related attributes (other than ``__spec__``) will no
+ longer be used directly by the import system during that module's
+ import. However, this does not impact use of those attributes
+ (e.g. ``__path__``) when loading other modules (e.g. submodules).
* Import-related attributes should no longer be added to modules
- directly.
+ directly, except by the import system.
* 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
@@ -459,8 +456,11 @@
sys.modues[spec.name] = module
try:
spec.loader.exec_module(module)
- except Exception:
- del sys.modules[spec.name]
+ except BaseException:
+ try:
+ del sys.modules[spec.name]
+ except KeyError:
+ pass
raise
return sys.modules[spec.name]
@@ -599,17 +599,6 @@
Omitted Attributes and Methods
------------------------------
-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.
-
-Here are other omissions:
-
There is no "PathModuleSpec" subclass of ModuleSpec that separates out
has_location, cached, and submodule_search_locations. While that might
make the separation cleaner, module objects don't have that distinction.
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list