01.12.17 20:12, Neil Schemenauer пише:
On 2017-12-01, Chris Angelico wrote:
Can you elaborate on where this is useful, please?
Introspection tools, for example, might want to look at the module
without executing it. Also, it is a building block to make lazy loading
of modules work. As Nick points out, importlib can do this already.
Currently, the IMPORT_NAME both loads the code for a module and also
executes it. The exec happens fairly deep in the guts of importlib.
This makes import.c and ceval.c mutually recursive. The locking gets
complicated. There are hacks like _call_with_frames_removed() to hide
the recursion going on.
Instead, we could have two separate opcodes, one that gets the module
but does not exec it (i.e. a function like __import__() that returns a
future) and another opcode that actually does the execution. Figuring
out all the details is complicated.
The IMPORT_NAME opcode is highly optimized. In most cases it just looks
up in sys.modules and check that the module is not imported right now.
I suppose two opcodes will hit performance. And I don't see how this
could simplify the code.
I suppose the existing importlib machinery already supports loading
modules without executing them. Maybe not with a single function, but
with a combination of 2-3 methods. But what you want to get? The source?
The code object? What about modules implemented in C?
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/