Description
Since 3.7, PyEval_ThreadsInitialized() always returns non-zero and calling PyEval_InitThreads() is useless: Py_Initialize() now always creates the GIL. These functions were deprecated in Python 3.9 by PR #18892 (commit b4698ec) of issue #84058. What's New in Python 3.9:
* The :c:func:`PyEval_InitThreads` and :c:func:`PyEval_ThreadsInitialized`
functions are now deprecated and will be removed in Python 3.11. Calling
:c:func:`PyEval_InitThreads` now does nothing. The :term:`GIL` is initialized
by :c:func:`Py_Initialize()` since Python 3.7.
(Contributed by Victor Stinner in :issue:`39877`.)
Well, the removal missed Python 3.11.
PyEval_AcquireLock() and PyEval_ReleaseLock() don't update the current thread state and were deprecated in Python 3.2 by issue #55122:
These two functions are very low-level and no good to use outside the interpreter core (actually, inside the core I don't think they are useful either). We should deprecate them and recommend the thread-state aware functions instead. See issue #44960 for an example confusion.
The commit ebeb903 adds this entry to What's New in Python 3.2:
* The misleading functions :c:func:`PyEval_AcquireLock()` and
:c:func:`PyEval_ReleaseLock()` have been officially deprecated. The
thread-state aware APIs (such as :c:func:`PyEval_SaveThread()`
and :c:func:`PyEval_RestoreThread()`) should be used instead.
I propose to now removed these 4 deprecated functions.
In 2020, I already proposed to remove PyEval_AcquireLock() and PyEval_ReleaseLock() functions in https://bugs.python.org/issue39998 But I closed my issue when I discovered that they were part of the stable ABI. This is way to keep these functions in the stable ABI and remove them in the C API.