Phillip J. Eby wrote:
> At 08:39 PM 4/12/2006 +1000, Nick Coghlan wrote:
>> 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).
>
> I don't think that's going to work, sin
At 08:39 PM 4/12/2006 +1000, Nick Coghlan wrote:
>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).
I don't think that's going to work, since importing won't work until _imp
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()'.
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 retur
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
I just noticed that two stdlib modules (runpy and test.test_importhooks)
contain reimplementations of the base PEP 302 algorithm, or loaders
wrapping the standard (pre-302) import machinery.
Meanwhile, the 'imp' module exports an undocumented IMP_HOOK constant
(since Python 2.3), that is used i
