[Import-SIG] PEP 489: Multi-phase extension module initialization; version 5
encukou at gmail.com
Thu May 21 02:50:07 CEST 2015
On Thu, May 21, 2015 at 12:39 AM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> On Wed, May 20, 2015 at 4:16 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On 21 May 2015 at 00:56, Eric Snow <ericsnowcurrently at gmail.com> wrote:
>>> On Wed, May 20, 2015 at 4:55 AM, Petr Viktorin <encukou at gmail.com> 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.
More information about the Import-SIG