gh-110415: move datetime global state into module state

[costasgambit]

datetime has types and various singletons defined as static global variables. _datetime_exec() has an initialisation step that writes into those structs on module import.

If the module is imported by the main interpreter and a sub-interpreter, or by two sub-interpreters, then the process crashes.

This is a first draft MR that:

• Moves the global bits of state into a DateTimeState struct / _PyModule_GetState
• Changes module initialisation to use PyModuleDef_Init with Py_MOD_PER_INTERPRETER_GIL_SUPPORTED
• Changes the type definitions to use the more modern slots style

• Issue: sub-interpreters: datetime segfaults if imported from two sub-interpreters #110415

[cpython-cla-bot]

The following commit authors need to sign the Contributor License Agreement:

• costas@mollybet.com

Click the button to sign:

[bedevere-app]

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

[bedevere-app]

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

[bedevere-app]

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

[bedevere-app]

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

[bedevere-app]

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

[erlend-aasland]

See previous work:

• gh-71587: Isolate _datetime #102995

[erlend-aasland]

./python -m test -R : test_datetime results in 39 failures and 7 errors; please investigate.

[costasgambit]

I'm closing this, since it's not finished yet and is a duplicate.

The test failures in question are due to a global (and rather bad-smelling) capsule object that I hadn't gotten round to yet.

If dealing with that would involve a C api change then some process will be required.

However, arguably with a bit of effort the capsule could be made to work if used from the main interpreter only and throw if one attempts to re-import it from elsewhere. That way that particular C api will stay the same for legacy extensions that rely on it, but the datetime module itself can become sub-interpreter compatible.

[erlend-aasland]

Yeah, the encapsulated C API is a big pain. One (or possibly the only) possibility is to put the module state into the interpreter state. No matter how it is solved, it will break all users of the datetime C API (which is quite a few). There is no quick or easy fix :(