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

Just van Rossum just@letterror.com
Mon, 30 Dec 2002 17:29:52 +0100

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