[Import-sig] Re: Long-awaited imputil comments
Wed, 16 Feb 2000 14:56:49 -0500
> I kindof lost track here, is it ok if I take a step back?
> I don't like the chaining aspect of imputil.py.
> What's needed is pluggable importers. Once proposal I remember (I think it
> was also Greg's) was that elements on sys.path could be importer instances.
> Is this still being proposed?
The "stable" version of imputil uses a chain. The CVS version
uses sys.path to hold importers (well, it's got one foot in each
> I also vaguely remember someone saying that this was not optimal, since
> it's a 2-dimensional problem: there's a list of directories/files to
> search, and a list of importers.
People were thinking in terms of "policy" importers - which
would, indeed, be unmanagable. Importers are based on "turf"
(to which we're currently trying to add "policy" hooks, at least
for certain kinds of importers). So a decently written importer
knows very quickly whether the request belongs to him.
> Would it make sense to add a new variable
> to the sys module, called "importers" or something, which contains a list
> of, erm, importers? And drop the __import__ hook. People would plug the
> import mechanism by manipulating sys.importers instead of mucking with
> __builtin__.__import__. Importers could then traverse sys.path, or use
> their own list of things.
As it stands now (CVS version, looking to be in the std dist,
but not the core), an ImportManager uses the __import__
hook and developers put their importers on sys.path.
A policy hook would probably go into the FileSystemImporter,
(where it would get activated when a directory on sys.path
was searched), but it wouldn't go searching sys.path itself.