RE: [Python-Dev] New and Improved Import Hooks
My current sys.import_hooks patch implements #3 and I think that's the most logical thing to do; after all sys.path may not be meaningful for a hook. #2 makes little sense I guess. #1 could be an option, but, given the current state of import.c, would be a lot harder to implement. I also think that #3 is the most efficient scheme, as the hook can save some local state while traversing sys.path.
Have you looked at Gordon McMillan's import utilities? He handles this by having a "shadowpath" in the manager which maps sys.path entries to "Owners", where each Owner is responsible for loading from one location (directory, zipfile, whatever). I'm convinced you're reinventing the wheel here, at least in part. (But reinventing it in C, rather than Python, so it's not a completely bad thing :-)) Paul.
Moore, Paul wrote:
Have you looked at Gordon McMillan's import utilities? He handles this by having a "shadowpath" in the manager which maps sys.path entries to "Owners", where each Owner is responsible for loading from one location (directory, zipfile, whatever).
I'm convinced you're reinventing the wheel here, at least in part. (But reinventing it in C, rather than Python, so it's not a completely bad thing :-))
In the meantime things have changed: death to sys.import_hooks, and yay to arbitrary objects on sys.path. I think this is more or less the same as iu.py, except that there's no need for a "shadowpath" (if not a string, the sys.path item _is_ the "owner"). Just
participants (2)
-
Just van Rossum
-
Moore, Paul