Feature or enhancement
Isolate the _curses extension module. This means turning most global variables into module state variables.
Globals in the _curses extension module:
| Name |
C type |
Notes |
| PyCursesVersion |
const char[] |
Hard-coded C string; can remain a global |
| PyCursesError |
PyObject * |
|
| initialised_setupterm |
int |
Tells whether setupterm() has been called to initialise terminfo |
| initialised |
int |
Tells whether initscr() has been called to initialise curses |
| initialisedcolors |
int |
Tells whether start_color() has been called to initialise color usage |
| screen_encoding |
int |
|
| PyCursesWindow_Type |
PyTypeObject * |
Must convert to heap type |
| ModDict |
PyObject * |
|
There is also a capsule with a C API. I'm not sure if this needs special handling wrt. PEP-489, but the _curses C API exposes three of the global variables1 directly. That said, those three variables are all guards for curses specific initialisation; it may make sense to keep these variables global; I don't know yet. The capsule C API also uses the _curses exception object (curses.error). Altering or removing the _curses C API is a breaking change and must follow the deprecation cycle of PEP-387.
Apart from the capsule C API issues, converting the remaining global variables to module state variables seem to be an easy task; most of them are used in either module functions or class methods. We can store the state in the PyCursesWindow_Type object for easy access and minimal churn.
Pitch
This is needed in order to support a per-interpreter GIL.
Previous discussion
https://github.com/ericsnowcurrently/multi-core-python/wiki/0-The-Plan
Linked PRs
Feature or enhancement
Isolate the
_cursesextension module. This means turning most global variables into module state variables.Globals in the
_cursesextension module:setupterm()has been called to initialiseterminfoinitscr()has been called to initialise cursesstart_color()has been called to initialise color usageThere is also a capsule with a C API. I'm not sure if this needs special handling wrt. PEP-489, but the _curses C API exposes three of the global variables1 directly. That said, those three variables are all guards for curses specific initialisation; it may make sense to keep these variables global; I don't know yet. The capsule C API also uses the _curses exception object (
curses.error). Altering or removing the _curses C API is a breaking change and must follow the deprecation cycle of PEP-387.Apart from the capsule C API issues, converting the remaining global variables to module state variables seem to be an easy task; most of them are used in either module functions or class methods. We can store the state in the
PyCursesWindow_Typeobject for easy access and minimal churn.Pitch
This is needed in order to support a per-interpreter GIL.
Previous discussion
https://github.com/ericsnowcurrently/multi-core-python/wiki/0-The-Plan
Linked PRs
_cursesextension module #104732Footnotes
initialised_setupterm,initialisedcolors, andinitialised↩