[Import-SIG] PEP proposal: Per-Module Import Path

[Eric Snow]

On Aug 1, 2013 8:36 AM, "Brett Cannon" <brett at python.org> wrote:
> If you're going to do that, why stop at types.SimpleNamespace and not
move all the way to a module object? Then you can simply start moving to
APIs which take the module object to be operated on and the various methods
in the loader, etc. and just fill in details as necessary; that's what I
would do if I got to redesign the loader API today since it would simplify
load_module() and almost everything would just become a static method which
set the attribute on the module (e.g.
ExecutionLoader.get_filename('some.module') would become
ExecutionLoader.filename(module) or even ExecutionLoader.__file__(module)
which gets really meta as you can then have a decorator which checks for a
non-None value for that attribute on the module and then returns it as a
short-circuit instead of calling the method). Only drawback I see is it not
being easy to tell if a module has been initialized or not, but I don't
view that as a critical issue. IOW introduce new_module()/fresh_module().
>
> Even if types.SimpleNamespace is kept I do like the idea. Loaders could
shift to working only off of the object and have their __init__ method
standardized to take a single argument so what import is told about and
what loaders work with is the same. Basically it becomes a caching
mechanism of what finders can infer so that loaders can save themselves the
hassle without complicated init call signatures.

This is pretty much exactly what I've been thinking about since PyCon.  The
only difference is that I have a distinct ModuleSpec class and modules
would get a new __spec__ attribute.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20130801/9066258d/attachment.html>