[Python-Dev] New and Improved Import Hooks

[Just van Rossum]

M.-A. Lemburg wrote:

> Here's a sketch:
> 
> 1. User programs register import hooks based on REs which are
>     used to match the entries in sys.path, e.g. ".*\.zip" for
>     ZIP importers (caching could help in improving the mapping
>     performance).
> 
> 2. When Python sees an import request, it scans sys.path and
>     creates hook objects for each entry which it then calls
>     to say "go look and check whether you have module X" until
>     one of the hooks succeeds.
> 
> 3. Python then uses the hook object to complete the import
>     in much a similar way as e.g. SAX parsers call out to
>     event handlers.

Nice; the hooks can then be cached in a dict, as in iu.py, with the path entry
as the key.

This makes bootstrapping a bit harder, though, as now we also need re/sre/_sre
to be available before hooked imports can work...

> The idea is to reuse as much of the existing import machinery
> as possible -- writing these hooks in C wouldn't be too hard
> either.

That's exactly what my patch already does: it leaves most of import.c in tact,
it adds no duplication.

I'd argue that *implementation*-wise it's simpler to just allow the sys.path
entry to handle the request. I also don't see a problem with it design-wise,
apart from b/w compatibility issues (which I think are non-issues if we use str
subclasses).

Are people against of the whole *idea* of having non-strings on sys.path, or is
it "only" a b/c compatibility concern?

Just