On Fri, 3 Dec 1999, Guido van Rossum wrote:
... Great response. I think we know where we each stand. Please go ahead with a new design. (That's trust, not carte blanche.)
Accepted gratefully. Thx.
Just one thought: the more I think about it, the less I like sys.importers: functionality which is implemented through sys.importers must necessarily be placed either in front of all of sys.path or after it. While this is helpful for "canned" apps that want *everything* to be imported from a fixed archive, I think that for regular Python installations sys.path should remain the point of attack. In particular, installing a new package (e.g. PIL) should affect sys.path, regardless of the way of delivery of the modules (shared libs, .py files, .pyc files, or a zip archive).
Okay. I'll design with respect to this model. To be explicit/clear and to be sure I'm hearing you right: sys.path may contain Importer instances. Given the name FOO, the system will step through sys.path looking for the first occurence of FOO (looking in a directory or delegating). FOO may be found with any number of (configurable) file extensions, which are ordered (e.g. ".so" before ".py" before ".isl").
I'm not too worried about code that inspects sys.path and expects certain invariants; that code is most likely interfering with the import mechanism so should be revisited anyway.
The Benevolent Dictator has spoken. So be it. :-)
On the lone .pyc issue: I'd like to see this disappear when using the filesystem, I see no use for it there if we support .pyc files in zip archives.
No problem. This actually creates a simplification in the system, as I'm seeing it now. I'm also seeing opportunities for a code reorg which may work towards MAL's issues with performance. I hope to have something in two or three weeks. I also hope people can be patient :-), but I certainly wouldn't mind seeing some alternative code! Cheers, -g -- Greg Stein, http://www.lyra.org/