[Python-Dev] difficulty of implementing phase 2 of PEP 302 in Python source
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
More information about the Python-Dev