[Python-Dev] Write All New Import Hooks (PEP 302) in Python, Not C

[James C. Ahlstrom]

Guido van Rossum wrote:

>>Python already has an import hook, namely __import__.  PEP
>>302 adds three more hooks: sys.path_hooks, sys.meta_path and
>>sys.path_importer_hooks.  The idea of four import hooks is
>>already fishy.
> 
> There's no path_importer_hooks; there's path_importer_cache,

Ooops, sorry.  I meant sys.path_importer_cache.

> but
> that's not a new hook, it's a cache for the path_hooks hook.  So I
> think the PEP proposes only two new hooks.

I disagree.  It is publicly available in sys, and the PEP specifies
it can be replaced or modified.  And if you want to add a hook, it
is easier to put it into sys.path_importer_cache than to add it
to the list in sys.path_hooks.  If you add it to sys.path_hooks,
you must clear its entry in sys.path_importer_cache too.

>>That is a lot of external changes.  That is a lot of code
>>written in C.
> 
> Um, last I looked, most of the code written in C was specific to the
> zip importer; only a relatively small amount of code was added to
> import.c (about 10%).

I agree 90% of the C would be needed anyway.

>>I think the proper import hook design is to write Python's
>>import mechanism in Python along the lines of Greg's imputil.py
>>and Gordon's iu.py.

> That's a design that I have had in mind long ago, but I don't see it
> happening soon, because it would be a much larger overhaul of
> import.c.

Is there some reason you need hooks right away?  A current
application?

> I'm not so sure.  In practice, hooks are used for two things: import
> from other media than directories (e.g. zip files), and supporting
> additional filename extensions that trigger special transformations.

The PEP 302 hooks do not support the second case very well when the
files with special extensions are in zip archives.  Adding the hook
replaces the zip hook, as all PEP 302 hooks are alternatives to
each other.

JimA