gh-71587: Isolate _datetime

[erlend-aasland]

• Issue: Datetime NoneType after calling Py_Finalize and Py_Initialize #71587

[erlend-aasland]

Observations:

• the (fishy) time and datetime memory optimisations may need to go; for now, I tore them out
• it may be beneficial to store state in object context instead of passing it around
• the exposed C API is still using a global variable; this is unfortunate

[erlend-aasland]

@ericsnowcurrently, regarding the datetime C API:

Currently, the encapsulated datetime C API is exposed as a global variable:

cpython/Include/datetime.h

Lines 196 to 197 in e375bff

	/* Define global variable for the C API and a macro for setting it. */
	staticPyDateTime_CAPI*PyDateTimeAPI=NULL;

I guess we could move this to the interpreter state instead. Thoughts?

FTR, if we run the ref leak bots on this PR, they fail because of the datetime C API tests in testcapi:

cpython/Modules/_testcapi/datetime.c

Lines 8 to 29 in e375bff

	staticPyObject*
	test_datetime_capi(PyObject*self, PyObject*args)
	{
	if (PyDateTimeAPI) {
	if (test_run_counter) {
	/* Probably regrtest.py -R */
	Py_RETURN_NONE;
	}
	else {
	PyErr_SetString(PyExc_AssertionError,
	"PyDateTime_CAPI somehow initialized");
	returnNULL;
	}
	}
	test_run_counter++;
	PyDateTime_IMPORT;
	if (PyDateTimeAPI) {
	Py_RETURN_NONE;
	}
	returnNULL;
	}

[vstinner]

Would it be possible to split the PR into multiple parts? Example:

• PR 1: Add a module state, refer a few static types there, and pass the state to the easy places to retrieve the type
• PR 2: Slowly, convert static types, one by one
• PR 3: Dirty changes
• PR 4: The final beautiful change which just remove the old code

[erlend-aasland]

Would it be possible to split the PR into multiple parts? Example:

• PR 1: Add a module state, refer a few static types there, and pass the state to the easy places to retrieve the type
• PR 2: Slowly, convert static types, one by one
• PR 3: Dirty changes
• PR 4: The final beautiful change which just remove the old code

Definitely!

[vstinner]

This function name is misleading. Can you please rename it to create_datetime_capi()?

[erlend-aasland]

I agree, but I think we should do that in a separate PR. The get_datetime_capi is not introduced by this PR; it is already in place.

[vstinner]

Something is strange here. But you should better address it in a separated PR (to keep this one as small as possible). Apparently, PyObject_GC_Track() is simply never called and so Py_TPFLAGS_HAVE_GC, traverse() and clear() functions seem to alll be unused (useless).