My concern is unnecessarily losing portability between the builtin module and the non-builtin one.

This PR avoids a crash not by locking but forcing the main interpreter initialize the _datetime static types, which I think is almost equivalent to the following change in _datetimemodule.c:

PyMODINIT_FUNC
PyInit__datetime(void)
{
+   if (PyDateTime_DateType.tp_subclasses == NULL) {
+       PyInterpreterState *interp = PyInterpreterState_Get();
+       // main interp currently checks a module before subinterp imports
+       assert(_Py_IsMainInterpreter(interp));
+       init_static_types(interp, 0);
+   }
    return PyModuleDef_Init(&datetimemodule);
}

Hmm, that feels really hacky.

I wouldn't call the movement of _datetime to static being totally unnecessary, because _datetime exposes a C API via a capsule. If _datetime isn't included with the build of Python, things using the capsule are very likely to crash, so it makes more sense to me to require it. Are there people actually disabling _datetime in their builds?

Hmm, that feels really hacky.

The crash can be avoided even on pure Python level, and managed static extsension types are already special only for _datetime. The C API is likely to be redesigned in the future, which will be a standard way to shared extensions including _datetime.

Are there people actually disabling _datetime in their builds?

Not sure about disabling. On Windows, _datetime is a built-in module that can be switched to a DLL. I know someone who want to use such a DLL as a plugin.

Right, there are several ways to fix this that work, but I'm trying to find the fix that is the most correct. Relying on implementation details like tp_subclasses is a little more maintenance if we ever change type initialization, and it also muddies our general rules about how static types should work. I see several options:

1. Make _datetime static, as it is in this PR. This makes the most sense, but I guess it could compromise compatibility in some niche cases.
2. Initialize static types in the PyInit_ function. This works, but will probably lead to some other issues because it mixes single and multi-phase initialization, which isn't supposed to be work.
3. Import _datetime in _interpreters. I really don't like this fix because it won't fix subinterpreters created via the C API.
4. Import _datetime in new_interpreter. This slows down initialization and is also a bit of a hack.
5. Make _PyStaticType_InitForExtension thread-safe. I think this will be needlessly complex.
6. Serialize calls to _PyStaticType_InitForExtension (gh-136421: Fix crash when _datetime is been initialized in multiple sub-interpreters #136422). This works but again hurts the story about static types, and is technically more of a bottleneck.

We have to find a balance between correctness and simplicity, and I'm not yet sure which that is.

1. Make _datetime static, as it is in this PR. This makes the most sense, but I guess it could compromise compatibility in some niche cases.

This is at least a feature change more than a bug fix.

Yeah, you're right. I'd be fine with a bandaid fix for 3.14 if you want to make a PR. The PyInit_ approach probably works best, but I don't fully understand why we need the tp_subclasses check.

Still rough example, but checking tp_subclasses is an alternative to PyType_HasFeature(PyDateTime_DateType, Py_TPFLAGS_READY). I'm not sure which is better on free-threading. Both must be kept in the main interpreter in its life, which means interp_count is at least 1 in the runtime state and the subinterp shutdown cannot invoke fini_static_type() as final.

During the _datetime exec phase, the main interpreter probably needs to skip init_static_types() to not increase interp_count.