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

Antoine Pitrou solipsis at pitrou.net
Sun Sep 1 15:03:51 CEST 2013


On Sun, 1 Sep 2013 11:28:36 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> * PEP 3121 with a size of "0". As above, but avoids the module state APIs
> in order to support reloading. All module state (including type
> cross-references) is stored in hidden state (e.g. an instance of a custom
> type not exposed to Python, with a reference stored on each custom type
> object defined in the module, and any module level "functions" actually
> being methods of a hidden object). Still doesn't support loading a *fresh*
> copy due to the hidden PEP 3121 module cache.

Not sure what you mean by that:

>>> import atexit
>>> id(atexit)
140031896222680
>>> import sys
>>> del sys.modules['atexit']
>>> import atexit
>>> id(atexit)
140031896221400


> Due to refcounting, all instances of Python objects qualify as mutable
> state.

That's an overly broad definition. Many objects are shared between
subinterpreters without any problems (None, the empty tuple, built-in
types and most C extension types, etc.). As long as the state is
an internal implementation detail, there shouldn't be any problem.

> I wouldn't be willing to make the call about which of stateless vs stateful
> is more common without a lot more research :)
> 
> They're both common enough that I think they should both be well supported,
> and making the "no custom C level state" case as simple as possible.

Agreed.

Regards

Antoine.




More information about the Python-Dev mailing list