Apply suggestions from code review

Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>

Author: ZeroIntensity

peps/pep-0797.rst

@@ -5,7 +5,7 @@ Discussions-To: Pending
 Status: Draft
 Type: Standards Track
 Requires: 683
-Created: 16-Jul-2025
+Created: 17-Jul-2025
 Python-Version: 3.15
 Post-History: `01-Jul-2025 <https://discuss.python.org/t/97306>`__
 
@@ -160,14 +160,14 @@ on some common objects, such as ``None``, ``True``, or ``False``.
 Lastly, immortality is also faster than deferred reference counting
 (:c:func:`PyUnstable_Object_EnableDeferredRefcount`), which is used for
 mitigating reference count contention on some objects on the free-threaded build.
-It would be nice to allow users (likely large C API wrappers) to take advantage
-of that speedup.
+It would be nice to allow users, for example C API binding generators, to take advantage
+of this speedup.
 
 Deallocators Rely On the Interpreter State
 ------------------------------------------
 
 Another, less intuitive, danger of reference counting is that when the
-object's reference count reaches zero, it immediately tries to get freed.
+object's reference count reaches zero, it immediately tries to deallocate itself.
 In doing so, an object will release its memory back to CPython's object allocator
 (typically via :c:func:`PyObject_GC_Del` or :c:func:`PyObject_Free`). This
 allocator is per-interpreter, so it is unsafe to try to release an object's
@@ -228,13 +228,13 @@ return ``SSTATE_INTERNED_IMMORTAL`` instead.
 Changes to Object Finalization
 ******************************
 
-The C API function, :c:func:`PyObject_CallFinalizer`, must be able to
-de-duplicate calls to immortal objects, even if they're non-GC types.
+The :c:func:`PyObject_CallFinalizer` function must be able to
+de-duplicate calls to finalize immortal objects, even if they're non-GC types.
 
 Immortalization APIs
 ********************
 
-This PEP introduces two new semi-public APIs for making an object immortal:
+This PEP introduces two new APIs for making an object immortal:
 :c:func:`PyUnstable_Immortalize` and :func:`sys._immortalize`.
 
 .. c:function:: int PyUnstable_Immortalize(PyObject *obj)
@@ -324,8 +324,8 @@ that reference counts are unstable:
 
 .. _brought up: https://discuss.python.org/t/72006
 
-Destructors Must Use ``tp_finalize``
-------------------------------------
+Destructors Must Use :c:member:`~PyTypeObject.tp_finalize`
+----------------------------------------------------------
 
 Once again, this should already be true for all extensions.
 Since Python 3.4 (:pep:`442`), :c:member:`~PyTypeObject.tp_finalize` alongside
@@ -543,8 +543,8 @@ to modify the reference count of any object visible to a user, as it could
 have been made immortal and is now deleted. As such, the deferred memory bank
 should be cleared at the very end of an interpreter's life.
 
-Preventing Reference Cycle UAFs
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Preventing Reference Cycle Use After Frees
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Before any destruction of immortal objects starts to happen,
 deferred memory deletion needs to be enabled.