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

[Eric Snow]

On Aug 1, 2013 8: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?

This is basically what I've been thinking of as a new ModuleSpec type,
though with some methods as well.

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