Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork32.4k
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 whethersetupterm() has been called to initialiseterminfo |
initialised | int | Tells whetherinitscr() has been called to initialise curses |
initialisedcolors | int | Tells whetherstart_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 ofPEP-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 thePyCursesWindow_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