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

On 01/18/2018 04:30 AM, Nick Coghlan wrote:
> 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.

I'm not sure that's something to try too hard to design for. What are 
the benefits?
If a module is to do something useful with -m, it will need to be 
changed anyway. If it just sets up a namespace, using `import *` instead 
of -i should work fine.