Re: PEP proposal: Per-Module Import Path

On 1 August 2013 23:18, Brett Cannon <[email protected]> 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?

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia