Remove distracting hyperlinks.

Author: ZeroIntensity

peps/pep-0788.rst

@@ -205,11 +205,11 @@ created by the author of this PEP:
     erroneously call the C API inside ``Py_BEGIN_ALLOW_THREADS`` blocks or
     omit ``PyGILState_Ensure`` in fresh threads.
 
-Again, :c:func:`PyGILState_Ensure` gets an :term:`attached thread state`
-for the thread on both with-GIL and free-threaded builds.
-An attached thread state is always needed to call the C API, so
-:c:func:`PyGILState_Ensure` still needs to be called on free-threaded builds,
-but with a name like "ensure GIL", it's not immediately clear that that's true.
+Again, :c:func:`PyGILState_Ensure` gets an attached thread state for the
+thread on both with-GIL and free-threaded builds. An attached thread state is
+always needed to call the C API, so :c:func:`PyGILState_Ensure` still needs
+to be called on free-threaded builds, but with a name like "ensure GIL", it's
+not immediately clear that that's true.
 
 .. _pep-788-subinterpreters-gilstate:
 
@@ -234,7 +234,7 @@ used on objects shared between the threads.
 
 For example, if the thread had access to object A, which belongs to a
 subinterpreter, but then called :c:func:`PyGILState_Ensure`, the thread would
-have an :term:`attached thread state` pointing to the main interpreter,
+have an attached thread state pointing to the main interpreter,
 not the subinterpreter. This means that any GIL assumptions about the
 object are wrong, because there is no synchronization between the two GILs.