Description
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
Footnotes
-
initialised_setupterm,initialisedcolors, andinitialised↩
Metadata
Metadata
Assignees
Labels
Projects
Status