gh-110415: move datetime global state into module state - #110420
gh-110415: move datetime global state into module state#110420costasgambit wants to merge 9 commits into
Conversation
|
Most changes to Python require a NEWS entry. Please add it using the blurb_it web app or the blurb command-line tool. |
|
Most changes to Python require a NEWS entry. Please add it using the blurb_it web app or the blurb command-line tool. |
|
Most changes to Python require a NEWS entry. Please add it using the blurb_it web app or the blurb command-line tool. |
|
Most changes to Python require a NEWS entry. Please add it using the blurb_it web app or the blurb command-line tool. |
|
Most changes to Python require a NEWS entry. Please add it using the blurb_it web app or the blurb command-line tool. |
|
See previous work: |
|
|
|
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. |

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: