René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"The `datetime` C API is not thread-safe","articleBody":"# Bug report\n\n### Bug description:\n\n`datetime` has a C API that we expose through a [global variable](https://github.com/python/cpython/blob/da7f4e4b22020cfc6c5b5918756e454ef281848d/Include/datetime.h#L197). This does not work well under multiple threads. For example, if `PyDateTime_IMPORT` fails in one thread while another thread is invoking the datetime C API, then that will set `PyDateTimeAPI` to `NULL`, leading to `NULL` pointer dereferences in the original thread. \n\nThis global variable also forces us to do some nasty hacks with subinterpreters because it exposes static types. I helped fix this a few months ago by making `_datetime` static (see [this thread](https://discuss.python.org/t/datetime-should-be-a-static-module/98857)), but there are probably other issues that I haven't found yet.\n\nI think a bandaid fix would be to make `PyDateTimeAPI` a thread-local variable, but I suspect that would break a lot of things, nor would that fix this for subinterpreters. More generally, we could deprecate `PyDateTime_IMPORT` and `PyDateTimeAPI` in favor of letting users manage the pointer on their own, but I don't know if we can do this without too many code changes (see #141543 and #83785 for the docs side).\n\ncc @pganssle\n\n### CPython versions tested on:\n\nCPython main branch\n\n### Operating systems tested on:\n\n_No response_","author":{"url":"https://github.com/ZeroIntensity","@type":"Person","name":"ZeroIntensity"},"datePublished":"2025-11-14T16:30:19.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":2},"url":"https://github.com/141563/cpython/issues/141563"}