Isolate the _curses extension module

[erlend-aasland]

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 variables¹ 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

• gh-101714: Isolate _curses extension module #104732

Footnotes

1. initialised_setupterm, initialisedcolors, and initialised ↩

[chgnrdv]

@erlend-aasland, don't mind if I work on this one? :)

[erlend-aasland]

@erlend-aasland, don't mind if I work on this one? :)

Sure, go ahead; I don't have time for this at the moment.

[erlend-aasland]

There might be a WIP PR open by me. Feel free to pick up where I left.

[chgnrdv]

@erlend-aasland, sorry, I can't find any. It's not a problem though, because I almost finished my own work and will submit a PR soon (I hope so).

[erlend-aasland]

Nice. You can ping me and @kumaraditya303 when you're ready.

[erlend-aasland]

I'm not sure it is worth it isolating _curses; is there a real use case where one would run curses any other place than the main interpreter? See also #103092 (comment).

I think we should consider just leaving it as it is.

cc. @ericsnowcurrently

[ericsnowcurrently]

Yeah, the status quo is: it won't get imported in isolated subinterpreters. That should be fine.

[erlend-aasland]

Yep. Closing as wont-fix.