Re: PEP 547: Could we implement a usable "get_code()" for extension modules?

On 18 January 2018 at 03:19, Petr Viktorin <[email protected]> wrote:
> On 01/17/2018 05:08 PM, Nick Coghlan wrote:
>> I'm fairly sure that wouldn't actually work right though, as I expect
>> the descriptor protocol would lead to the "wrong" module getting
>> passed in to the extension module functions :(
>
> Let me suggest another potential direction we (or at least I) haven't
> explored yet: what about working to make the __main__ module either
> replaceable, or unused until we know what it should be?
>
> I remember you saying that's not feasible, so I haven't tried anything, but
> I don't remember an explanation. How sure are you that that rabbit hole is
> deeper than the one we're in now?

If I remember rightly, the main challenges with that were ensuring that:

- "python -i" ended up dropping back in to the right module
- multiprocessing startup still did the right thing

It's likely worth taking another look at the idea in light of the
startup refactoring that's happened in 3.7, but I also expect that
approach to have similar problems to the
"spec.loader.exec_in_module(mod)" case: it's an approach that would
require changes on the code execution side, rather than being
something we could enable transparently through existing importlib
APIs.

That said, I'd be a lot more amenable to that outcome if it gave us
the ability to execute *all* extension modules, even those using
Py_mod_create or single-phase initialisation.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia