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

[Just van Rossum]

James C. Ahlstrom wrote:

> >>It changes the meaning of __import__.
> > 
> > Where did you get that idea?
> 
> I believe the base (unreplaced) __import__ function does not find
> hooked imports. It follows that __import__ will not find modules in
> zip archives.

Not true. (It couldn't be true, simply because any import statement
*physically* goes through __import__.)

It _is_ true that zipimports won't neccesarily work when using existing
__import__ replacements. How big a deal that is, I honestly don't know.

> > This is backwards: iu.py implements a superset of PEP 302 (with
> > different details). So you have that now.
> 
> Which is why I think we should fix iu.py instead of
> add more public import hooks.  It is OK with me to
> use your import hooks as an internal feature to
> implement zip imports.

And I see *nothing* against making them public. They solve real problems
for real applications (besides zipimport) as well.

> > PEP 302 allows customizing *parts* of the import mechanism without
> > having to deal with most of these pitfalls and complications. It
> > allows completely independend components to add hooks that will
> > work together seamlessy. This is not true for replacing __import__.
> 
> I don't believe PEP 302 provides hooks that work together.  It
> provides only one hook for each component of sys.path, and replaces
> any hook that was already there.

And __import__ *does* provide this, how? Sure, PEP 302 is not a full
replacement of (say) ihooks.py, but it's nevertheless a vast improvement
over raw __import__ hooks.

Just