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

[Brett Cannon]

On Thu, Aug 1, 2013 at 10:00 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 1 August 2013 23:18, Brett Cannon <brett at python.org> wrote:
> >> I see 2 as the best one.  Is it really too late to change the return
> type
> >> of FileFinder.find_loader()? If we simply can't bear the backward
> >> compatibility risk (no matter how small <wink>),
> >
> > We unfortunately can't. It would require a new method which as a stub
> would
> > call the old API to return the proper object (which is fine if you can
> come
> > up with a reasonable name).
>
> Just musing on this one for a bit.
>
> 1. We still have the silliness where we call "find_module" on metapath
> importers to ask them for a loader.
> 2. We have defined an inflexible signature for find_loader on path
> entry finders (oops)
> 3. There's other interesting metadata finders could expose *without*
> loading the module
>
> So, how does this sound: add a new API called "find_module_info" for
> both metapath importers and path entry finders (falling back to the
> legacy APIs). This would return a simple namespace potentially
> providing the following pieces of information, using the same rules as
> the corresponding loader does for setting the module attributes
> (http://docs.python.org/3/reference/import.html#loaders):
>
>     __loader__
>     __name__
>     __package__
>     __path__
>     __file__
>     __cached__
>     __indirect__
>
> (We could also lose the double underscores for the namespace
> attributes, but I quite like the symmetry of keeping them)
>
> Thoughts?


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20130801/1aa1ec8d/attachment.html>