Re: PEP 489: Multi-phase extension module initialization; version 5

On Thu, May 21, 2015 at 12:39 AM, Eric Snow <[email protected]> wrote:
> On Wed, May 20, 2015 at 4:16 PM, Nick Coghlan <[email protected]> wrote:
>> On 21 May 2015 at 00:56, Eric Snow <[email protected]> wrote:
>>> On Wed, May 20, 2015 at 4:55 AM, Petr Viktorin <[email protected]> wrote:
>>>> The point is that exec_module doesn't a priori depend on the module
>>>> being in sys.modules, which I think is a good thing.
>>>
>>> Well, there's an explicit specification about how sys.modules is used
>>> during loading.  For post-exec sys.modules lookup specifically,
>>> https://docs.python.org/3.5//reference/import.html#id2.  The note in
>>> the language reference says that it is an implementation detail.
>>> However, keep in mind that this PEP is a CPython-specific proposal.
>>>
>>> That said, I'm only -0 on not matching the sys.modules lookup behavior
>>> of module loading.  It could be okay if we were to document the
>>> behavior clearly.  My concern is with having different semantics even
>>> if it only relates to a remote corner case.  It may be a corner case
>>> that someone will rely on.
>>
>> We *will* match the semantics for the *overall* loading process. What
>> Petr is saying is that *while* executing the "execution slots",
>> they'll all receive the object returned by Py_mod_create (or the
>> automatically created module if that slot is not defined), rather than
>> any replacement injected into sys.modules.
>>
>> There's no Python level parallel for that "multiple execution slots"
>> behaviour, so it makes sense to define the semantics based on
>> simplicity of implementaiton and the fact we want to encourage the use
>> of Py_mod_create for extension modules over sys.modules injection.
>
> I was thinking along those same lines.  I'm okay with that rationale.
> The PEP should be updated to clarify this point and its rationale.

There's no provision in the machinery to call multiple different
implementations of exec_module. And all sys.modules
lookup/manipulation is done by the machinery, so it doesn't make sense
to do it in ExtensionFileLoader.exec_module, either.
I believe that now, with the pseudo-code overview, this is clearer, so
a rationale isn't needed (the reason it was needed in the first place
is that the PEP was confusing.)
I will clarify the semantics Py_mod_exec section, though.