Addressed Comments

Author: eduardo-elizondo

Doc/whatsnew/3.14.rst

@@ -417,8 +417,7 @@ New Features
   which has an ambiguous return value.
   (Contributed by Irit Katriel and Erlend Aasland in :gh:`105201`.)
 
-* Modified the ``_PyUnicode_ClearInterned`` function to always delete all
-  interned strings during a call to :c:func:`Py_Finalize`. This
+* :c:func:`Py_Finalize` now deletes all interned strings. This
   is backwards incompatible to any C-Extension that holds onto an interned
   string after a call to :c:func:`Py_Finalize` and is then reused after a
   call to :c:func:`Py_Initialize`.  Any issues arising from this behavior will

Misc/NEWS.d/next/Core and Builtins/2024-01-15-18-11-48.gh-issue-113190.OwQX64.rst

@@ -1,20 +1 @@
-This updates the interned string deallocation function
-``_PyUnicode_ClearInterned`` to delete all interned strings during runtime
-finalization when calling ``Py_Finalize``, regardless of their reference
-count.
-
-Worth noting that if an extension accidentally holds onto a interned string,
-even after calling Py_Finalize, it will result in use-after-free error,
-leaving the user to a potential vulnerabilities. That said, the history of
-how these interned strings are handled have been changing during throughout
-different versions.
-
-For example, in Python 3.9 and older, interned strings were never deleted.
-Only special builds for Valgrind and Purity cleared them at exit. In Python
-3.10 and 3.11, interned strings are always deleted at exit. In Python 3.12,
-interned strings are deleted only if Python is built in debug mode: they
-are not deleted in release mode. In Python 3.13, interned strings will
-now be all deleted.
-
-Given how the guarantees changed throughout different versions, it is not
-expected that users actively rely on this behavior for their extensions.
+:c:func:`Py_Finalize` now deletes all interned strings.