[Python-Dev] Created branch for PEP 302 phase 2 work (in C)

[Phillip J. Eby]

At 01:01 PM 10/2/2006 -0700, Brett Cannon wrote:
>In the interest of time I have decided to go ahead and do the PEP 302 
>phase 2 work in C.

Just FYI, it's not possible (so far as I know) to implement phase 2 while 
maintaining backward compatibility with existing 2.x code.  So this work 
shouldn't go back to the 2.x trunk without discussion of those issues.

Essentially, I abandoned trying to do the phase 2 work for Python 2.5 
because there's too much code in the field that depends on the current 
order of when special/built-in imports are processed vs. when PEP 302 
imports are processed.  Thus, instead of adding new PEP 302 APIs (like 
get_loader) to 'imp', I added them to 'pkgutil'.  There are, I believe, 
some notes in that module's source regarding what the ordering issues are 
w/meta_path vs. the way import works now.

That having been said, we could possibly have a transition for 2.6, but 
everybody who's written any PEP 302 emulation code (outside of pkgutil 
itself) would have to adapt their code somewhat.

I'm surprised, however, that you think working on this in C is going to be 
*less* time than it would take to simply replace __import__ with a Python 
function that reimplements PEP 302...  especially since pkgutil contains a 
whole lot of the code you'd need, e.g.:


     def __import__(...):
         ...
         loader = pkgutil.find_loader(fullname)
         if loader is not None:
             module = loader.load_module(fullname)
             ...

And much of the rest of the above can probably be filled out by swiping 
code from ihooks, imputil, or other Python __import__ implementations.