[Python-Dev] Pre-PEP: Redesigning extension modules (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Sun Sep 1 15:03:51 CEST 2013
- Previous message: [Python-Dev] Pre-PEP: Redesigning extension modules
- Next message: [Python-Dev] Pre-PEP: Redesigning extension modules
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message: [Python-Dev] Pre-PEP: Redesigning extension modules
- Next message: [Python-Dev] Pre-PEP: Redesigning extension modules
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]