[Python-Dev] Import redesign [LONG]

Greg Stein gstein@lyra.org
Sat, 4 Dec 1999 05:12:32 -0800 (PST)


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/