Proposal: Expose _PyEval_IsGILEnabled as an unstable CPython C API

[VanshAgarwal24036]

I’d like to propose exposing _PyEval_IsGILEnabled as an unstable, CPython-specific C API.

Context

• CPython recently added sys._is_gil_enabled() as a Python-level diagnostic API.
• Some C extensions would like to make similar diagnostic or configuration decisions without calling back into Python (e.g. via PySys_GetAttr + PyObject_CallNoArgs).
• During discussion on Discourse, a CPython core developer suggested that exposing an existing helper such as _PyEval_IsGILEnabled would be preferable to introducing a new API that requires passing a PyInterpreterState *.

Discourse discussion

https://discuss.python.org/t/c-api-for-querying-whether-the-gil-is-enabled-pyinterpreterstate-isgilenabled/105776

Related GitHub issue

#143747

Proposal

• Expose _PyEval_IsGILEnabled as an unstable, CPython-specific C API.
• The API would live under Include/cpython/ and would not be part of the stable ABI.
• The intended use is diagnostics, reporting, or choosing reasonable defaults in C extensions (e.g. selecting threading vs multiprocessing backends), not for controlling GIL behavior.

I’m seeking feedback and approval from the C API Working Group on whether exposing this API is acceptable before proceeding with any implementation.

[ZeroIntensity]

This isn't any different from #143747, so let's just continue the discussion on that issue and on DPO. Also, please do not use AI to generate your responses in its entirety, as many of us find it extremely rude. If you're not a native English speaker, you can use it for translation help, but please don't let the AI compose ideas and arguments for you.

[VanshAgarwal24036]

Understood, thanks for the clarification.

I’ll keep the discussion continue on #143747 and on Discourse, and I won’t open further issues.
Apologies for the confusion.