[Python-Dev] difficulty of implementing phase 2 of PEP 302 in Python source

[Paul Moore]

> Phillip J. Eby schrieb:

> > I would say that the C code is *delicate*, not necessarily bad.  In most
> > ways, it's rather straightforward, it's actually the requirements that are
> > complex.  :)

>From what I recall, that's right. The C code's main disadvantage is
that it isn't very well commented (as far as I recall) and there's no
documentation of precisely what it's trying to achieve (insofar as
there isn't a precise spec for how importing works in the Python docs,
covering all the subtleties of things like package imports, package
__path__ entries, reloading, etc etc...)

> > A Python implementation, however, would be a good idea to have around for
> > PyPy, Py3K, and other versions of Python, and as a refactoring basis for
> > writing any new C code.

It would also provide the basis of a much better spec - both because a
clear spec would need to be established before you could write it, and
because Python code is inherently readable...

On 9/28/06, Thomas Heller <theller at python.net> wrote:
> FYI, Gordon McMillan had a Python 'model' of the import mechanism in his,
> (not sure if it was really named) "iu.py".  It was part of his installer utility,
> maybe the code still lives in the PyInstaller project.  IIRC, parts of pep 302 were
> inspired by his code.

That's right. Lots of the path importer and metapath stuff came from iu.py.

I have an oldish copy (Installer 5b5_2, from 2003) if you can't get it
anywhere else...

Paul.