Re: PEP 489: Multi-phase extension module initialization; version 5
Eric Snow <[email protected]> Wed, 20 May 2015 08:07:52 -0600
| Newsgroups | gmane.comp.python.import |
|---|---|
| Message-ID | <CALFfu7CKndjSn3bf3txpTSsnBnntdA18LjCA9JufKefX4Js28w@mail.gmail.com> |
On Wed, May 20, 2015 at 2:37 AM, Petr Viktorin <[email protected]> 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