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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4