[Import-SIG] PEP proposal: Per-Module Import Path
Nick Coghlan
ncoghlan at gmail.com
Thu Aug 1 16:00:24 CEST 2013
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?
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Import-SIG
mailing list