[Python-ideas] Provide a way to import module without exec body

Nick Coghlan ncoghlan at gmail.com
Sat Dec 2 22:26:52 EST 2017


On 3 December 2017 at 13:22, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 2 December 2017 at 07:55, Brett Cannon <brett at python.org> wrote:
>> 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 :) .
>
> In PEP 451 terms, I can definitely see the value in having
> CREATE_MODULE and EXEC_MODULE be separate opcodes (rather than having
> them be jammed together in IMPORT_MODULE the way they are now). While
> there'd still be some import machinery on the frame stack when the
> module code ran (due to the way the "exec_module" API is defined),
> there'd be substantially less of it.
>
> 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.

Re-reading my own post reminded me of another potentially harder
problem: IMPORT_MODULE also hides all the import cache management from
the eval loop. If you try to split creation and execution apart, then
that cache management becomes the eval loop's problem (since it needs
to know whether the module is already fully initialised or not after
the "GET_OR_CREATE_MODULE" step. That cache locking is fairly
intricate already, and exposing these to the eval loop as distinct
operations wouldn't make that any easier.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list