Fix some outdated references.

Author: ZeroIntensity

peps/pep-0788.rst

@@ -827,16 +827,16 @@ Using interpreter IDs for reference counting
 
 Some iterations of this API took an ``int64_t interp_id`` parameter instead of
 ``PyInterpreterState *interp``, because interpreter IDs cannot be concurrently
-deleted and cause use-after-free violations. :c:func:`PyInterpreterState_Hold`
-fixes this issue anyway, but an interpreter ID does have the benefit of
-requiring less magic in the implementation, but has several downsides:
+deleted and cause use-after-free violations. The reference counting APIs in
+this PEP sidestep this issue anyway, but an interpreter ID have the advantage
+of requiring less magic:
 
 -  Nearly all existing interpreter APIs already return a :c:type:`PyInterpreterState`
    pointer, not an interpreter ID. Functions like
    :c:func:`PyThreadState_GetInterpreter` would have to be accompanied by
    frustrating calls to :c:func:`PyInterpreterState_GetID`.
 -  Threads typically take a ``void *arg`` parameter, not an ``int64_t arg``.
-   As such, passing an interpreter pointer requires much less boilerplate
+   As such, passing a reference requires much less boilerplate
    for the user, because an additional structure definition or heap allocation
    would be needed to store the interpreter ID. This is especially an issue
    on 32-bit systems, where ``void *`` is too small for an ``int64_t``.
@@ -845,7 +845,7 @@ requiring less magic in the implementation, but has several downsides:
    the native thread gets a chance to attach. The problem with using an
    interpreter ID is that the reference count has to be "invisible"; it
    must be tracked elsewhere in the interpreter, likely being *more*
-   complex than :c:func:`PyInterpreterState_Hold`. There's also a lack
+   complex than :c:func:`PyInterpreterRef_Get`. There's also a lack
    of intuition that a standalone integer could have such a thing as
    a reference count.