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. :( _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
