[Import-sig] Re: Long-awaited imputil comments

[Gordon McMillan]

Just wrote:

> I kindof lost track here, is it ok if I take a step back?
> 
> I don't like the chaining aspect of imputil.py. 
[snip]
> 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 
world).

> 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.

- Gordon