Fix Sphinx warnings.

python · ZeroIntensity · Jul 17, 2025 · Jul 17, 2025 · Jul 17, 2025 · Jul 17, 2025
commit 97a569e3ce64974220b4b18da450723e66c04b7f
@@ -157,7 +157,7 @@ or compromise compatibility with the stable ABI.
 Immortality is a clever way of fixing this problem, because by avoiding
 reference counting, there is no risk of data races. In fact, both
 subinterpreters and free-threading already use immortality for thread-safety
-on some common objects, such as :const:`None`, :const:`True`, or :const:`False`.
+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
@@ -247,12 +247,12 @@ This PEP introduces two new semi-public APIs for making an object immortal:
      collected type.
    * All finalization for an object must be done in
      :c:member:`~PyTypeObject.tp_finalize` by
-     :c:function:`PyObject_CallFinalizerFromDealloc`.
+     :c:func:`PyObject_CallFinalizerFromDealloc`.
 
    .. warning::
       Abuse of this function can result in high memory usage for a program.
 
-.. function:: _immortalize(obj)
+.. function:: sys._immortalize(obj)
 
    Make *obj* an :term:`immortal` object. This means that it will not be deallocated for the
    lifetime of the Python interpreter.
@@ -267,8 +267,6 @@ This PEP introduces two new semi-public APIs for making an object immortal:
       This function should be considered a low-level routine that most users should avoid. Making too many
       objects immortal can result in drastically higher memory usage for a program.
 
-   .. impl-detail:: This function is specific to CPython.
-
 Immortalization Contract
 ************************
 
@@ -332,7 +330,7 @@ Using the Object or Memory Domain is a Must
 -------------------------------------------
 
 For an object immortal on the heap, the object domain (:c:func:`PyObject_Malloc`
-or :c:func:`PyObject_GC_New`) or the memory domain (:c:func:`PyMem_Malloc`)
+or :c:macro:`PyObject_New`) or the memory domain (:c:func:`PyMem_Malloc`)
 must be used. Otherwise, the interpreter will not be able to hijack the
 object's allocator and will result in use-after-free violations during
 deallocation. Note that in 3.13, using the object domain is already a
@@ -389,11 +387,11 @@ Temporary Mortalization for Finalizers
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 It is documented (and expected with assertions) that finalizers are run with
-a reference count of 1 [#tp_dealloc_refcount]_, so each immortal object needs
-to be temporarily mortalized; this can be done with the private ``_Py_SetMortal``
-API that currently exists. After the finalizer is done, it must be
-immortalized again so other finalizers don't accidentally deallocate it in
-their own finalizers by releasing a reference.
+a reference count of 1, so each immortal object needs to be temporarily
+mortalized; this can be done with the private ``_Py_SetMortal`` API
+that currently exists. After the finalizer is done, it must be immortalized
+again so other finalizers don't accidentally deallocate it in their own
+finalizers by releasing a reference.
 
 In addition, an object might expect that its finalizer only be called by the
 garbage collector if the type doesn't call
@@ -615,7 +613,7 @@ In addition, this PEP only exposes an opt-in feature; types that don't support
 immortalization will continue to work as long as they are not immortalized.
 
 What if CPython Removes Immortality?
-------------------------------------
+************************************
 
 The APIs in this PEP are exposed as unstable, allowing CPython to
 remove them later on if it needs to.