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. _______________________________________________ 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