Greg Ward wrote:
> > - a hook either returns None ("module not found") or a two-tuple:
> > (loadfunc, cookie). loadfunc is a callable object that will
>
> Sounds sensible, but please s/cookie/data/ (or similar).
Ok.
> > be called with two arguments: the fullname and "cookie". The
> > cookie is just an arbitrary object, private to the hook. The
> > loaderfunc must return the imported module.
> > - (Currently it expects that the loaderfunc will insert the module
> > in sys.path, I'm not sure I like that. Actually, I am sure I
> ^^^^
>
> You really meant sys.module, right?
sys.modules actually ;-)
> > don't like that <wink>, but changing that would require more
> > changes to import.c that I'd like. I'll have to investigate.)
>
> I agree: if an import hook is not responsible for checking sys.modules
> before doing an import, it should not be responsible for updating
> sys.modules after an import.
I hadn't even looked at it that way, but yeah, that's an excellent rationale...
But: they _may_ do so if they desire; a module is even allowed to stuff a whole
different object into sys.modules instead of itself, so I'll have to be careful.
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