[Import-SIG] PEP 489: Multi-phase extension module initialization; version 5

Eric Snow ericsnowcurrently at gmail.com
Wed May 20 16:07:52 CEST 2015


On Wed, May 20, 2015 at 2:37 AM, Petr Viktorin <pviktori at redhat.com> wrote:
> On 05/20/2015 02:33 AM, Eric Snow wrote:
  [snip]
>> Won't frozen modules be likewise affected?
>
> No, frozen modules are Python source, just not loaded from a file.

Isn't the mechanism similar to builtins?  Regardless, I was hopeful
that we could fix FrozenImporter at the same time that we fixed
BuiltinImporter.

  [snip]
>> It may also be worth outlining how PyModuleDef_Init will work.
>
> That's hard to do in Python syntax, since most of what it does is ensure
> the def is a valid PyObject. I'll explain it in a different section.
> It's a very small, idempotent function:
>
> PyObject*
> PyModuleDef_Init(struct PyModuleDef* def)
> {
>     if (def->m_base.m_index == 0) {
>         max_module_number++;
>         Py_REFCNT(def) = 1;
>         Py_TYPE(def) = &PyModuleDef_Type;
>         def->m_base.m_index = max_module_number;
>     }
>     return (PyObject*)def;
> }
>
> The code is lifted straight from PyModule_Create2.
>
> The m_index is bookkeeping for for PyState_FindModule, so it's unused
> for modules with multi-phase init, but I didn't want to break the
> invariant that it's set up together with Py_TYPE.

Okay.  Thanks for the explanation.  So really PyModuleDef_Init does
some bookkeeping and that's it.

-eric


More information about the Import-SIG mailing list