![](https://secure.gravatar.com/avatar/370e0e9efabdb50594f28d0cfdafdcbc.jpg?s=120&d=mm&r=g)
NOTE: This is copied straight from Python-Ideas mailing list.
CPython at the very least has 2 different type of native states: Interpreter & Module state. Unfortunately, the multi-phase initialization has a weakness when it comes to Module states.
You can't access the module state without a pointer to the module. PyState_GetModule from a standpoint looks to be the obvious answer to use, but it's documentation states it's unfit for multi-phase initialization.
I'm proposing an idea here for discussion on a new state system for at least CPython.
Tier 1: Core state
- This state lives within CPython's core binary and exists the entire
lifetime of the binary. - The data held within this state is available to the main interpreter and subsequent sub-interpreters. (Example: sys.executable) Tier 2-1: Interpreter state (Branches from Core state)
- This state lives within CPython's core binary and is tied to a specific
interpreter. - The data held within this state is only available to the interpreter it's tied to. (Example: Modules loaded into memory) Tier 2-2: Extension state (Branches from Core state)
- This state lives within any CPython's core binary EXCEPT it's size and
structure is defined by the extension CPython has loaded. - The purpose of this state is to allow an extension to hold data that can't be tied to a specific module. (Examples can be: Windows WSA, MySQL) Tier 3-1: Thread state (Branches from Interpreter State)
- This state lives within CPython's core binary and is tied to a specific
Python thread (IE: Threading library threads), - The data held within this state is only available to the thread it's tied to. (No known examples available) Tier 3-2: Module state (Branches from Interpreter State)
- This type of state is already available in CPython, explaining it is not
required.