[PEP 451] It pays to run make before committing.
This commit is contained in:
Eric Snow
parent
23dc54157b
commit
a1c321efbb
44
pep-0451.txt
44
pep-0451.txt
|
|
@ -35,7 +35,7 @@ proposal. Finally, it's worth explaining a few other existing terms
|
|||
with which people may not be so familiar. For the sake of context, here
|
||||
is a brief summary of all three groups of terms and concepts. A more
|
||||
detailed explanation of the import system is found at
|
||||
[import_system_docs]_.
|
||||
[#import_system_docs]_.
|
||||
|
||||
name
|
||||
----
|
||||
|
|
@ -180,7 +180,7 @@ information and to pass around within the import system. Secondly,
|
|||
there's an API void between finders and loaders that causes undue
|
||||
complexity when encountered. The PEP 420 (namespace packages)
|
||||
implementation had to work around this. The complexity surfaced again
|
||||
during recent efforts on a separate proposal. [ref_files_pep]_
|
||||
during recent efforts on a separate proposal. [#ref_files_pep]_
|
||||
|
||||
The `finder`_ and `loader`_ sections above detail current responsibility
|
||||
of both. Notably, loaders are not required to provide any of the
|
||||
|
|
@ -524,8 +524,8 @@ the reason why find_spec() has
|
|||
`the "existing" parameter <The "existing" parameter of find_spec()>`_.
|
||||
|
||||
The semantics of reload will remain essentially the same as they exist
|
||||
already [reload-semantics-fix]_. The impact of this PEP on some kinds
|
||||
of lazy loading modules was a point of discussion. [lazy_import_concerns]_
|
||||
already [#reload-semantics-fix]_. The impact of this PEP on some kinds
|
||||
of lazy loading modules was a point of discussion. [#lazy_import_concerns]_
|
||||
|
||||
|
||||
ModuleSpec
|
||||
|
|
@ -737,15 +737,15 @@ able to trivially identify a reload situation on their own.
|
|||
Two alternatives were presented to the "existing" parameter:
|
||||
Loader.supports_reload() and adding "existing" to Loader.exec_module()
|
||||
instead of find_spec(). supports_reload() was the initial approach to
|
||||
the reload situation. [supports_reload]_ However, there was some
|
||||
the reload situation. [#supports_reload]_ However, there was some
|
||||
opposition to the loader-specific, reload-centric approach.
|
||||
[supports_reload_considered_harmful]_
|
||||
[#supports_reload_considered_harmful]_
|
||||
|
||||
As to "existing" on exec_module(), the loader may need other information
|
||||
from the existing module (or spec) during reload, more than just "does
|
||||
this loader support reloading this module", that is no longer available
|
||||
with the move away from load_module(). A proposal on the table was to
|
||||
add something like "existing" to exec_module(). [exec_module_existing]_
|
||||
add something like "existing" to exec_module(). [#exec_module_existing]_
|
||||
However, putting "existing" on find_spec() instead is more in line with
|
||||
the goals of this PEP. Furthermore, it obviates the need for
|
||||
supports_reload().
|
||||
|
|
@ -838,7 +838,7 @@ Other Changes
|
|||
Open Issues
|
||||
===========
|
||||
|
||||
* In the `Finders`_ section, the PEP specifies returning None (or using
|
||||
\* In the `Finders`_ section, the PEP specifies returning None (or using
|
||||
a different loader) when the found loader does not support loading into
|
||||
an existing module (e.g during reload). An alternative to returning
|
||||
None would be to raise ImportError with a message like "the loader does
|
||||
|
|
@ -885,16 +885,6 @@ While "ModuleSpec.is_package" would be a simple additional attribute
|
|||
the artificial (and mostly erroneous) distinction between modules and
|
||||
packages.
|
||||
|
||||
Others left out:
|
||||
|
||||
* Add ModuleSpec.submodules (RO-property) - returns possible submodules
|
||||
relative to the spec.
|
||||
* Add ModuleSpec.loaded (RO-property) - the module in sys.module, if
|
||||
any.
|
||||
* Add ModuleSpec.data - a descriptor that wraps the data API of the
|
||||
spec's loader.
|
||||
* Also see [cleaner_reload_support]_.
|
||||
|
||||
The module spec `Factory Functions`_ could be classmethods on
|
||||
ModuleSpec. However that would expose them on *all* modules via
|
||||
``__spec__``, which has the potential to unnecessarily confuse
|
||||
|
|
@ -929,29 +919,31 @@ Others left out:
|
|||
any.
|
||||
* Add ModuleSpec.data - a descriptor that wraps the data API of the
|
||||
spec's loader.
|
||||
* Also see [cleaner_reload_support]_.
|
||||
* Also see [#cleaner_reload_support]_.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [ref_files_pep]
|
||||
.. [#ref_files_pep]
|
||||
http://mail.python.org/pipermail/import-sig/2013-August/000658.html
|
||||
|
||||
.. [import_system_docs] http://docs.python.org/3/reference/import.html
|
||||
.. [#import_system_docs] http://docs.python.org/3/reference/import.html
|
||||
|
||||
.. [cleaner_reload_support]
|
||||
.. [#cleaner_reload_support]
|
||||
https://mail.python.org/pipermail/import-sig/2013-September/000735.html
|
||||
|
||||
.. [lazy_import_concerns]
|
||||
.. [#lazy_import_concerns]
|
||||
https://mail.python.org/pipermail/python-dev/2013-August/128129.html
|
||||
|
||||
.. [reload-semantics-fix] http://bugs.python.org/issue19413
|
||||
.. [#reload-semantics-fix] http://bugs.python.org/issue19413
|
||||
|
||||
.. [supports_reload_considered_harmful]
|
||||
.. [#supports_reload]
|
||||
https://mail.python.org/pipermail/python-dev/2013-October/129913.html
|
||||
.. [#supports_reload_considered_harmful]
|
||||
https://mail.python.org/pipermail/python-dev/2013-October/129971.html
|
||||
|
||||
.. [exec_module_existing]
|
||||
.. [#exec_module_existing]
|
||||
https://mail.python.org/pipermail/python-dev/2013-October/129933.html
|
||||
|
||||
Copyright
|
||||
|
|
|
|||
Loading…
Reference in New Issue