GeezerVison

@colesbury Are you ready to be merged or need more additional work?

@corona10 thanks! it is ready to merge

define the Py_NOGIL macro

I dislike double negation, would it be possible to have a companion macro, like Py_HAVE_GIL? For example, Py_HAVE_GIL can be always defined, as 0 or 1. Or Py_HAVE_GIL would not be defined if Py_NOGIL is defined.

In the long term, I would prefer that Python has no GIL by default, but so we would only have special code for the legacy build where Python has a GIL. Well, maybe that's a politic question :-)

@vstinner, I generally agree with you about double negation, but I think in this case it's more convenient to define a Py_NOGIL macro or equivalent.

• All or nearly all of the special code will be fore running without the GIL. I don't expect any special code for running with the GIL. (Especially because --disable-gil builds still need to support running with the GIL as a fallback.)
• Previous versions of CPython (and PyPy) wouldn't have the Py_HAVE_GIL macro defined, so C-API extensions can't rely on it always being defined, even if we do so in 3.13.
• It's a bit more convenient to write #ifdef Py_NOGIL than #if Py_HAVE_GIL == 0
• The Py_NOGIL macro matches the PEP draft

None of these reasons are tremendously important, but the choice of macro name doesn't seem tremendously important either.

It's just a remark, I'm fine with Py_NOGIL.