[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