[Python-Dev] difficulty of implementing phase 2 of PEP 302 in Python source (original) (raw)

Paul Moore p.f.moore at gmail.com
Thu Sep 28 21:25:55 CEST 2006

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.

More information about the Python-Dev mailing list