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

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.findloader()' and have it return a PEP > 302-compatible loader object, even for cases that would normally be handled > via 'imp.loadmodule()'. In such cases, the loader returned would be an > instance of one of a loader class similar to those in runpy, > testimporthooks, and setuptools (which also has similar code).

runpy tries to retrieve "imp.getloader()" before falling back to its own emulation - switching that to look for "findloader()" 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 getfilename() 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. :(

More information about the Python-Dev mailing list