> From: Just van Rossum [mailto:just@letterror.com]
>
> 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(...)
It seems to me there needs to be two separate sets of import hooks.
1. Module import hooks.
2. Source import hooks.
Module import hooks are the type being discussed for sys.import_hooks - a
sequence of callables which are called one after the other until a module is
successfully imported.
Source import hooks provide the exact mechanism for doing an import from a
particular data source.
Doing this, in effect we would have the following algorithm ...
for hook in sys.import_hooks:
hook(...)
and the algorithm for the builtin import hook would be ...
for p in sys.path:
for hook in sys.source_import_hooks:
hook(p, ...)
which would end up being the default behaviour.
Individual module import hooks could (and probably should) use the
appropriate source import hooks.
I think this would suit all requirements, whilst being both general and
clean. It would provide a simple mechanism for allowing .tar files in
sys.path, internet imports, etc.
Tim Delaney
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