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

On 01/17/2018 05:45 AM, Nick Coghlan wrote:
> On 17 January 2018 at 03:08, Brett Cannon <[email protected]> wrote:
>> On Tue, 16 Jan 2018 at 05:43 Marcel Plch <[email protected]> wrote:
>>> I took a look at the get_code() and it works basically just as is in
>>> Nick's mail. Spec and name are accessible through passed globals.
>>> Unlike the current proposal for -m switch for extension modules [PR
>>> 1761], this approach does not require multiphase initialization. That
>>> means that every module can be run with this switch just as it is
>>> right now, including the standard library:
>>>
>>>      $ python -im math
>>>      >>> print(e)
>>>      2.718281828459045
>>>
>>> Should I open a bug for this, or reuse [bpo-30403]?
>>
>> If you want, although a new issue is also totally justified.
>>
>>> Or does this need a PEP?
>>
>> I don't think so since you're just implementing a pre-existing API and this
>> doesn't require changing any pre-existing semantics.
> 
> While this is technically true, I think handling this as a revision of
> PEP 547 would be a better idea, as I'd like to get more folks to think
> through the implications of that proposed "ns.update(module.__dict__)"
> step.
> 
> For example, it may be better to rely on PEP 562's module level
> __getattr__ and __dir__ instead (delegating both to the underlying
> "real" module) rather than duplicating the entire namespace, but that
> would mean that Marcel's "python -im math" example wouldn't work any
> more (since the __getattr__ hook doesn't get invoked for internal
> access from *within* the module). On the positive side, it would mean
> that the underlying module attributes can't accidentally overwrite the
> attributes in the wrapper module.
> 
> Whether we use namespace duplication or PEP 562, both of them have the
> problem that attribute *rebinding* won't work, since they'll only
> affect the wrapper namespace. I think we can live with that, but we'll
> likely want to expose a dunder-name to let folks access the underlying
> "real" module (e.g. make the variable name "__module__" rather than
> "module", and then use the PEP 562 approach so there's no risk of
> accidentally overwriting it).

Hm, the more I think about it, the more I don't like the namespace copy.
The `python -im math` is cute, but doesn't really solve any immediate 
problem. `from math import *` practically does the same thing, and is 
way more obvious.
The main rationale behind making -m work for extension modules was to 
make them behave like pure-Python ones -- e.g. if you Cythonize 
something, everything will keep working as before. That's not the case 
here, and adding `__module__` would be just piling on workarounds.


> There's also an open question around how this would interact with PEP
> 399 if that was implemented - assuming the wrapper module gets
> injected into sys.modules under the given name, should it replace that
> with the inner implementation module?
> 
> Cheers,
> Nick.