On 2017-12-03, Nick Coghlan wrote:
> There'd be some subtleties around handling backwards compatibility
> with __import__ overrides (essentially, CREATE_MODULE would have to
> revert to doing all the work, while EXEC_MODULE would become a no-op),
> but the basic idea seems plausible.
Right now (half-baked ideas), I'm thinking:
IMPORT_RESOLVE
Gives the abs_name for a module (to feed to _find_and_load())
IMPORT_LOAD
Calls _find_and_load() with abs_name as argment. The body of
the module is not executed yet. Could return a spec or a module
with the spec that contains the code object of the body.
IMPORT_EXEC
Executes the body of the module.
IMPORT_FROM
Calls _handle_fromlist().
Props to Brett for making importlib in such as way that this clean
separation should be relatively easy to do.
To handle custom __import__ hook, I think we can do the following.
Have each opcode detect if __import__ is overridden. There is
already such test (import_name fast path). If it is overridden,
IMPORT_RESOLVE and IMPORT_LOAD will gather up info and then
IMPORT_EXEC will call __import__() using compatible arguments.
Inititally, the benefit of making these changes is not some
performance improvement or some functionalty we didn't previously
have. importlib does all this already and probably just as quickly.
The benefit that the import system becomes more understandable.
If we decide it is a good idea, we could expose hooks for these
opcodes. Not like __import__ though. Maybe there should be a
function like sys.set_import_hook(<op>, func). That will keep ceval
fast as it will know if there is a hook or not, without having to
crawl around in builtins.
Regards,
Neil
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
