> 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.
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