[Import-SIG] PEP 547: Could we implement a usable "get_code()" for extension modules?

[Nick Coghlan]

On 17 January 2018 at 03:08, Brett Cannon <brett at python.org> wrote:
> On Tue, 16 Jan 2018 at 05:43 Marcel Plch <gmarcel.plch at gmail.com> 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).

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.

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