[Python-Dev] Another approach for the import mechanism

[Gustavo Niemeyer]

> > - Alternative importers are only considered when the default importer
> >   mechanism fails (each entry in the path at a time, so that
> >   precedence is preserved).
>
> Far too restrictive. You seem to be saying (unless I misunderstand)
> that an alternative import can't override an element on the
> traditional sys.path.

Why not? I belive it's exactly the other way around. You have
more possibilities with that scheme.

> Is there to be no way to replace existing system components by
> providing replacements in zip files, in the same way that I could
> currently replace httplib by putting my own httplib in a directory
> which I then place at the beginning of sys.path?

I'm not sure if I understood what you're trying to say. But if I
understood that correctly, there are even more possibilities:

Having one of:

/some/dir/httplib/__init__.zip
/some/dir/httplib.zip

You'd do:

sys.path.insert(0, "/some/dir")

> > - Alternative importers, when activated, would be given the module name
> >   being imported, and would look for entries in the "current" iterated
> >   path by themselves.
>
> Huh? Why restrict alternative importers to using a path? What if my
> importer wants to provide randomly generated byte codes as part of a
> genetic programming experiment?

Then you'd have to work with ihooks. IIRC, none of the proposed
mechanisms would allow that.

Also, I wouldn't say that "randomly generated byte codes" should be
*imported*. Just compile it.

> > - A zip importer would, for example, look if the current iterated path
> >   have a file named "__init__.zip".
>
> ...and I'm not really sure what you mean by "iterated path".

for path in sys.path:
	import_default(path)
	import_alternate(path)

> I think I must be misunderstanding at a fairly basic level. This would
> seem pretty inflexible to me.

Does it look better now?

-- 
Gustavo Niemeyer

[ 2AAC 7928 0FBF 0299 5EB5  60E2 2253 B29A 6664 3A0C ]