Improve the abstract.

Author: ZeroIntensity

peps/pep-0797.rst

@@ -38,21 +38,18 @@ For example:
 .. code-block:: C
 
     static PyObject *
-    my_method(PyObject *self, PyObject *object) // METH_O
+    my_singleton_new(PyTypeObject *type, PyObject *args, PyObject *kwargs)
     {
-        if (PyUnstable_Immortalize(object) < 0) {
+        PyObject *self = type->tp_alloc(type, 0);
+        if (self == NULL) {
             return NULL;
         }
 
-        /* The object is now immortal, we can do whatever we want with it's
-           reference count without worrying about thread safety or leaks. */
-
-        // This is totally safe for an immortal object
-        for (int i = 0; i < 10; ++i) {
-            Py_DECREF(object);
+        if (PyUnstable_Immortalize(self) < 0) {
+            return NULL;
         }
 
-        Py_RETURN_NONE;
+        return self;
     }
 
 Or, in Python:
@@ -61,25 +58,12 @@ Or, in Python:
 
     import sys
 
-    my_own_singleton = object()
-    sys._immortalize(my_own_singleton)
-    assert sys._is_immortal(my_own_singleton)
-
-What Do We Mean By "Immortal"?
-******************************
-
-By immortal, we mean an object with an immortal reference count, per :pep:`683`.
-However, the main difference in this PEP is that the underlying behavior differs
-from the documentation, which states that the object is *never* deallocated:
+    my_singleton = object()
+    sys._immortalize(my_singleton)
+    assert sys._is_immortal(my_singleton)
 
-    Some objects are immortal and have reference counts that are never
-    modified, and therefore the objects are never deallocated.
-
-In this case, immortal objects are eventually deallocated, it's just that the user
-never really sees when that happens because they're freed during interpreter
-finalization. So, the term "immortal" throughout this PEP really means
-"never deallocated for the lifetime of the interpreter," rather than
-"never deallocated."
+Motivation
+==========
 
 What Problem Does Immortality Solve?
 ************************************
@@ -110,8 +94,6 @@ other areas of CPython, or in third-party libraries:
 
 .. _doing this in Cinder: https://engineering.fb.com/2023/08/15/developer-tools/immortal-objects-for-python-instagram-meta/
 
-Motivation
-==========
 
 Immortal Objects Must Remain in CPython
 ***************************************
@@ -179,9 +161,9 @@ Immortality is a Powerful Tool to Wield
 ***************************************
 
 In general, immortal objects seem to have a lot of applications that aren't
-immediately clear. For example, `Nanobind used immortal objects`_
-in its original :term:`free threading` implementation. It seems like it would
-have interesting use-cases for many places outside of CPython.
+immediately clear to CPython maintainers. For example, `Nanobind used immortal objects`_
+in its original :term:`free threading` implementation. So, it seems like immortality
+has interesting use-cases in third-party libraries.
 
 .. _Nanobind used immortal objects: https://github.com/wjakob/nanobind/pull/695