[Python-Dev] Created branch for PEP 302 phase 2 work (in C)
Phillip J. Eby
pje at telecommunity.com
Mon Oct 2 22:59:43 CEST 2006
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.:
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.
More information about the Python-Dev