It doesn't matter much, though, in that as long as we don't want to rewrite import.c as a whole we're stuck with the two-step scheme anyway.
I don't wish to seem difficult here, but didn't this start from the basis that import.c was a mess, Jim Ahlstrom's patch was going to make it worse, and we should clean it up rather than making it worse? Don't get me wrong, I'd like to see a better import hook mechanism. And I'd like to see zipfile imports. And I'd like to see the import code cleaned up. But iu.py does all I need from import hooks. Jim Ahlstrom's patch does zip imports. If Just's code doesn't clean up the import code, I quite honestly don't understand the point. I think this reinforces the need for a PEP. It would clearly describe the benefits of the patch - both in overall terms, and in comparison to the (more limited) scope of PEP 273. Paul.
Moore, Paul wrote:
But iu.py does all I need from import hooks. Jim Ahlstrom's patch does zip imports. If Just's code doesn't clean up the import code, I quite honestly don't understand the point.
I won't clean up import.c, but I don't want to make it any worse, which is IMO what the current zip import patch does. I *might* open doors for future cleansing, but that's all. My main motivation are still: - the mechanics of reading zip files should _not_ be in import.c - ditto for a directory caching scheme - to try to minimally patch import.c so that zipimport can relatively cleanly be plugged in (if this leads to a new & approved import scheme, that's merely a nice side effect) Just
participants (2)
-
Just van Rossum
-
Moore, Paul