Apply suggestions from code review

Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>

Author: ZeroIntensity

peps/pep-0788.rst

@@ -115,8 +115,8 @@ is severely limiting for users who want to do more than just execute Python
 code in their stream of calls (for example, C++ executing finalizers in
 *addition* to calling Python).
 
-Using :c:func:`Py_IsFinalizing` is insufficient
-***********************************************
+Using ``Py_IsFinalizing`` is insufficient
+*****************************************
 
 The :ref:`docs <python:gilstate>`
 currently recommend :c:func:`Py_IsFinalizing` to guard against termination of
@@ -167,8 +167,8 @@ finalization, because a daemon thread got hung while holding the lock. There
 are workarounds for this for pure-Python code, but native threads don't have
 such an option.
 
-We can't change finalization behavior for :c:func:`PyGILState_Ensure`
-*********************************************************************
+We can't change finalization behavior for ``PyGILState_Ensure``
+***************************************************************
 
 There will always have to be a point in a Python program where
 :c:func:`PyGILState_Ensure` can no longer acquire the GIL (or more correctly,
@@ -193,8 +193,8 @@ There are currently two public ways for a user to create and attach their own
 and :c:func:`PyGILState_Ensure`. The latter, :c:func:`PyGILState_Ensure`,
 is `significantly more common <https://grep.app/search?q=pygilstate_ensure>`_.
 
-:c:func:`PyGILState_Ensure` generally crashes during finalization
-*****************************************************************
+``PyGILState_Ensure`` generally crashes during finalization
+***********************************************************
 
 At the time of writing, the current behavior of :c:func:`PyGILState_Ensure` does not
 match the documentation. Instead of hanging the thread during finalization
@@ -217,15 +217,15 @@ created by the authors of this PEP:
     omit ``PyGILState_Ensure`` in fresh threads.
 
 Since Python 3.12, it is an :term:`attached thread state` that lets a thread
-invoke the C API. On with-GIL builds, holding an :term:`attached thread state`
+invoke the C API. On with-GIL builds, holding an attached thread state
 implies holding the GIL, so only one thread can have one at a time. Free-threaded
 builds achieve the effect of multi-core parallism while remaining
 ackwards-compatible by simply removing that limitation: threads still need a
 thread state (and thus need to call :c:func:`PyGILState_Ensure`), but they
 don't need to wait on one another to do so.
 
-Subinterpreters don't work with :c:func:`PyGILState_Ensure`
------------------------------------------------------------
+Subinterpreters don't work with ``PyGILState_Ensure``
+-----------------------------------------------------
 
 As noted in the :ref:`documentation <python:gilstate>`,
 ``PyGILState`` APIs aren't officially supported in subinterpreters:
@@ -443,12 +443,12 @@ replace :c:func:`PyGILState_Ensure` and :c:func:`PyGILState_Release`.
 
     Thread states created by this function are non-daemon by default. See
     :c:func:`PyThreadState_SetDaemon`. If the calling thread already has an
-    :term:`attached thread state` that matches *interp*, then this function
+    attached thread state that matches *interp*, then this function
     will mark the existing thread state as non-daemon and return. It will
     be restored to its prior daemon status upon the next
     :c:func:`PyThreadState_Release` call.
 
-    Return zero on success, and non-zero with the old :term:`attached thread state`
+    Return zero on success, and non-zero with the old attached thread state
     restored (which may have been ``NULL``).
 
 .. c:function:: void PyThreadState_Release()
@@ -457,7 +457,7 @@ replace :c:func:`PyGILState_Ensure` and :c:func:`PyGILState_Release`.
     :c:func:`PyThreadState_Ensure`.
 
     This function cannot fail, but may hang the thread if the
-    :term:`attached thread state` prior to the original :c:func:`PyThreadState_Ensure`
+    attached thread state prior to the original :c:func:`!PyThreadState_Ensure`
     was daemon and the interpreter was finalized.
 
 Deprecation of ``PyGILState`` APIs
@@ -653,7 +653,7 @@ they can still be used with this API:
 Asynchronous callback example
 *****************************
 
-As started in the Motivation_, there are many cases where it's desirable
+As stated in the Motivation_, there are many cases where it's desirable
 to call Python in an asynchronous callback, such as a signal handler. In that
 case, it's not safe to call :c:func:`PyInterpreterState_Hold`, because it's
 not guaranteed that :c:func:`PyThreadState_Ensure` will ever be called, which
@@ -718,8 +718,8 @@ A reference implementation of this PEP can be found
 Rejected Ideas
 ==============
 
-Using an interpreter ID instead of a interpreter state for :c:func:`PyThreadState_Ensure`
------------------------------------------------------------------------------------------
+Using an interpreter ID instead of a interpreter state for ``PyThreadState_Ensure``
+-----------------------------------------------------------------------------------
 
 Some iterations of this API took an ``int64_t interp_id`` parameter instead of
 ``PyInterpreterState *interp``, because interpreter IDs cannot be concurrently
@@ -773,8 +773,8 @@ This was ultimately rejected for two reasons:
    for code-generators like Cython to use, as there isn't any additional
    complexity with tracking :c:type:`PyThreadState` pointers around.
 
-Using ``PyStatus`` for the return value of :c:func:`PyThreadState_Ensure`
--------------------------------------------------------------------------
+Using ``PyStatus`` for the return value of ``PyThreadState_Ensure``
+-------------------------------------------------------------------
 
 In prior iterations of this API, :c:func:`PyThreadState_Ensure` returned a
 :c:type:`PyStatus` instead of an integer to denote failures, which had the