[Import-SIG] PEP 489: Multi-phase extension module initialization; version 5
encukou at gmail.com
Mon May 18 19:06:53 CEST 2015
On Mon, May 18, 2015 at 6:57 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 18 May 2015 18:27:50 +0200
> Petr Viktorin <encukou at gmail.com> wrote:
>> On Mon, May 18, 2015 at 5:58 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> > On Mon, 18 May 2015 17:32:13 +0200
>> > Petr Viktorin <encukou at gmail.com> wrote:
>> >> > A fast, easy way to access module "state" without defining global
>> >> > variables at the C level is required.
>> >> You can have a custom subclass, or you can use per-module state, or
>> >> put a capsule in the module dict.
>> > The latter two are cumbersome and inefficient. Only custom subclasses
>> > can make things easy and fast at the C level.
>> With per-module state, you need a one-liner macro, and a pointer
>> dereference at runtime. Is that too cumbersome and inefficient, or am
>> I missing something?
> The main problem is the PyState_FindModule() function. It's not
> terribly efficient, and most of all you have to check its return value
> for NULL.
Ah, but that one is orthogonal to per-module state. The
PyState_FindModule is concerned with finding "the" module
corresponding to a given PyModuleDef in a given interpreter.
The problem it attempts to solve is that the module can't easily be
passed around to all the places that need it. You'd actually have the
exact same problem with a custom subclass -- it's finding the module
instance that's the problem, not getting data from it.
The PEP actually discourages PyState_FindModule quite strongly: this
family of functions just doesn't work with modules initialized
multi-phase init. The PEP tells you that if you need
PyState_FindModule, we're sorry, and you should stick to the old way
of doing things until we solve the problem (and then it links to
preliminary discussion about the solution, which is out of its scope).
More information about the Import-SIG