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

Nick Coghlan ncoghlan at gmail.com
Wed Apr 12 12:39:46 CEST 2006


Phillip J. Eby wrote:
> 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.

Either works for me - I managed to momentarily forget that you're planning to 
write this in Python.

>> Would it be worth the effort to switch 'imp' to being a hybrid module?
> 
> I have no idea; what's a hybrid module?

In this particular case, it would be a Python module "imp.py" that included 
the line "from _imp import *" (where _imp is the current C-only module with a 
different name).

The Python module could then provide access to the bits which don't need to be 
blazingly fast and would be painful to write in C. It's proved to be a 
convenient approach in a few other places.

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

Yep. For example, one limitation of runpy.py is that it doesn't get the 
__file__ attribute right for module's inside a zip package - the zipimporter 
objects don't expose the information that run_module() needs in order to set 
the value correctly.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org


More information about the Python-Dev mailing list