<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, 1 Dec 2017 at 10:11 Neil Schemenauer <<a href="mailto:neil@python.ca">neil@python.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2017-12-01, Chris Angelico wrote:<br>
> Can you elaborate on where this is useful, please?<br>
<br>
Introspection tools, for example, might want to look at the module<br>
without executing it.  Also, it is a building block to make lazy loading<br>
of modules work.  As Nick points out, importlib can do this already.<br>
<br>
Currently, the IMPORT_NAME both loads the code for a module and also<br>
executes it.  The exec happens fairly deep in the guts of importlib.<br>
This makes import.c and ceval.c mutually recursive.  The locking gets<br>
complicated.  There are hacks like _call_with_frames_removed() to hide<br>
the recursion going on.<br>
<br>
Instead, we could have two separate opcodes, one that gets the module<br>
but does not exec it (i.e. a function like __import__() that returns a<br>
future) and another opcode that actually does the execution.  Figuring<br>
out all the details is complicated.<br>
<br>
Possible benefits:<br>
<br>
- importlib is simpler<br>
<br>
- reduce the amount of stack space used (removing recursion by<br>
  "continuation passing style").<br>
<br>
- makes profiling Python easier.  Tools like valgrind get confused<br>
  by call cycle between ceval.c and import.c.<br>
<br>
- easier to implement lazy loading of modules (not necessarily a<br>
  standard Python feature but will make 3rd party implementations<br>
  cleaner)<br>
<br>
I'm CCing Brett as I'm sure he has thoughts on this, given his intimate<br>
knowledge of importlib.  To me, it seems like __import__() has a<br>
terribly complicated API because it does so many different things.<br></blockquote><div><br></div><div>I have always assumed the call signature for __import__() was because the import-related opcodes pushed so much logic into the function instead of doing it in opcodes (I actually blogged about this at <a href="https://snarky.ca/if-i-were-designing-imort-from-scratch/">https://snarky.ca/if-i-were-designing-imort-from-scratch/</a>). Heck, the thing takes in locals() and yet never uses them (and its use of globals() is restricted to specific values so it really doesn't need to be quite so broad). Basically I wished __import__() looked like importlib.import_module().<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Maybe two opcodes is not even enough.  Maybe we should have one to<br>
resolve relative imports (i.e. import.c:resolve_name), one to load but<br>
not exec a module given its absolute name (i.e.  _find_and_load()<br>
without the exec), one to exec a loaded module, one or more to handle<br>
the horror of "fromlist" (i.e.  _handle_fromlist()).<br></blockquote><div><br></div><div>I have always wanted to at least break up getting the module and fromlist as separate opcodes, so +1 for that. Name resolution could potentially be done as an opcode as it relies on execution state pulled from the globals of the module, but the logic also isn't difficult so +0 for that (i.e. making an opcode that calls something more like importlib.import_module() is more critical to me than eliminating the 'package' argument to that call, but I don't view it as a bad thing to have another opcode for that either).<br></div><div><br></div><div>As for the completely separating the loading and execution, I don't have a need for what's being proposed so I don't have an opinion. I basically made sure Eric Snow structured specs so that lazy loading as currently supported works so I got what I wanted for basic lazy importing (short of the PyPI package I keep talking about writing to add a nicer API around lazy importing :) .<br></div><div><br></div><div>-Brett<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
<br>
  Neil<br>
</blockquote></div></div>