[Guido]
> > I'd be disappointed if adding zipfiles to sys.path wasn't possible.
> > After all that's what PEP 273 says.
[Samuele Pedroni]
> but - if I understand correctly - given the approach taken by the
> import_hooks patch there's the issue:
>
> consider all directories then all zipfiles
(or vice versa ;-)
> versus consider both kind of import sources according to the order in
> sys.path, which is the most natural extension.
Right. I admit I dismissed sys.path a wee bit too quickly when proposing an
alternative zipimport mechanism.
Regarding sys.import_hooks, I see three possibilities:
#1
for p in sys.path:
for hook in sys.import_hooks:
hook(p, ...)
#2
for hook in sys.import_hooks:
for p in sys.path:
hook(p, ...)
#3
for hook in sys.import_hooks:
# the hook can traversing sys.path if needed.
hook(...)
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.
I will change my zipimport hook (which _still_ isn't finished ;-) to also
traverse sys.path, and check for *.zip path endings.
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