[Python-Dev] Proposal: expose PEP 302 facilities via 'imp' and 'pkgutil'

[Phillip J. Eby]

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 
> PEP
> > 302-compatible loader object, even for cases that would normally be 
> handled
> > 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 
>PEP
>302 API.

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.  :(