On 02 December 2002, Just van Rossum said:
> I don't follow. In my scheme (which in the meantime I've partially
> implemented) any first import will be done by an import hook on
> sys.import_hooks, so you have full control.
Ahh! I get it, sorry. Makes sense now.
> If you mean that you can't
> hook imports that are already in sys.modules: yes, that's a feature
Agreed. Once something has been imported, the import hooks should not
be bothered with it again.
> - sys.import_hooks is a list of hooks
> - a hook is a callable object taking two arguments:
> [sub]modulename and path. Path is either the parents package's
> __path__ or None.
> - 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).
> 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?
> 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.
Greg
--
Greg Ward <gward@python.net> http://www.gerg.ca/
Clarke's Law:
Any sufficiently advanced technology is indistinguishable from magic.
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