[Python-Dev] Pre-PEP: Redesigning extension modules

[Antoine Pitrou]

On Sat, 31 Aug 2013 21:16:10 +0200
Stefan Behnel <stefan_ml at behnel.de> wrote:
> > Our experience is very different - my perspective is that the normal case
> > either eschews C level global state in the extension module, because it
> > causes so many problems, or else just completely ignores subinterpreter
> > support and proper module cleanup.
> 
> As soon as you have more than one extension type in your module, and they
> interact with each other, they will almost certainly have to do type checks
> against each other to make sure users haven't passed them rubbish before
> they access any C struct fields of the object. Doing a type check means
> that at least one type has a pointer to the other, meaning that it holds
> global module state.
> 
> I really think that having some kind of global module state is the
> exceedingly common case for an extension module.

Since we are eating our own dogfood here (and the work which prompted
this discussion was indeed about trying to make our extension modules
more cleanup-friendly), it would be nice to take a look at the Modules
directory and count which proportion of CPython extension modules have
state.

Caution: "state" is a bit vague here. Depending on which API you use,
custom extension types can be a part of "module state".

Regards

Antoine.