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

On 22 January 2018 at 20:09, Petr Viktorin <[email protected]> wrote:
> On 01/18/2018 04:30 AM, Nick Coghlan wrote:
>> 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.

Single phase isn't a big deal, but I think Py_mod_create compatibility
will be important for Cython - otherwise folks will need to choose
between "fast C level access to module globals" (via Py_mod_create and
preallocated slots) and "-m switch compatibility".

Cheers,
Nick.

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