A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2013-October/129897.html below:

[Python-Dev] PEP 451 update

[Python-Dev] PEP 451 updatePJ Eby pje at telecommunity.com
Sun Oct 27 17:37:00 CET 2013
On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Now, regarding the signature of exec_module(): I'm back to believing
> that loaders should receive a clear indication that a reload is taking
> place. Legacy loaders have to figure that out for themselves (by
> seeing that the module already exists in sys.modules), but we can do
> better for the new API by making the exec_module signature look like:
>
>     def exec_module(self, module, previous_spec=None):
>         # module is as per the current PEP 451 text
>         # previous_spec would be set *only* in the reload() case
>         # loaders that don't care still need to accept it, but can
> just ignore it

Just to be clear, this means that a lazy import implementation that
creates a module object without a __spec__ in the first place will
look like an initial import?  Or will that crash importlib because of
a missing __spec__ attribute?

That is, is reload()'s contract adding a new prerequisite for the
object passed to it?

(The specific use case is creating a ModuleType subclass instance for
lazy importing upon attribute access.  Pre-importlib, all that was
needed was a working __name__ attribute on the module.)
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4