[Python-Dev] Proposal: expose PEP 302 facilities via 'imp' and 'pkgutil'
Phillip J. Eby
pje at telecommunity.com
Wed Apr 12 00:12:32 CEST 2006
At 07:43 AM 4/12/2006 +1000, Nick Coghlan wrote:
>Phillip J. Eby wrote:
> > I propose to create a new API, 'imp.find_loader()' and have it return a
> > 302-compatible loader object, even for cases that would normally be
> > via 'imp.load_module()'. In such cases, the loader returned would be an
> > instance of one of a loader class similar to those in runpy,
> > test_importhooks, and setuptools (which also has similar code).
>runpy tries to retrieve "imp.get_loader()" before falling back to its own
>emulation - switching that to look for "find_loader()" instead would be fine
>(although I'd probably leave the emulation in place, since it allows the
>module to be used on 2.4 as well as 2.5).
I was proposing to move the emulation features (at least the classes) to
pkgutil, or in the alternative, making them a
published/documented/supported API, rather than private.
>Would it be worth the effort to switch 'imp' to being a hybrid module?
I have no idea; what's a hybrid module?
>runpy needs a get_filename() method, so it knows what to set __file__ too -
>currently its emulation supports that, but it isn't officially part of the
It sounds like maybe a new PEP is needed to document all the extensions to
the importer/loader protocols. :(
Interestingly, these are all more examples of where adaptation or generic
functions would be handy to have in the stdlib. Duck-typing protocols
based on attribute names are hard to extend and have to wait for new
library releases for upgrades. :(
More information about the Python-Dev