> 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4