Remove the 10-year deprecation.

Also some minor fixups.

Author: ZeroIntensity

peps/pep-0788.rst

@@ -389,16 +389,18 @@ subinterpreters:
 
 - :c:func:`PyGILState_Ensure`: :c:func:`PyThreadState_Swap` & :c:func:`PyThreadState_New`
 - :c:func:`PyGILState_Release`: :c:func:`PyThreadState_Clear` & :c:func:`PyThreadState_Delete`
-- :c:func:`PyGILState_GetThisThreadState`: :c:func:`PyThreadState_Get`
+- :c:func:`PyGILState_GetThisThreadState`: :c:func:`PyThreadState_Get` (roughly)
 - :c:func:`PyGILState_Check`: ``PyThreadState_GetUnchecked() != NULL``
 
-This PEP specifies a ten-year deprecation for these functions (while remaining
-in the stable ABI), mainly because it's expected that the migration will be a
-little painful, because :c:func:`PyThreadState_Ensure` and
-:c:func:`PyThreadState_Release` aren't drop-in replacements for
+This PEP specifies a deprecation for these functions (while remaining
+in the stable ABI), because :c:func:`PyThreadState_Ensure` and
+:c:func:`PyThreadState_Release` will act as more-correct replacements for
 :c:func:`PyGILState_Ensure` and :c:func:`PyGILState_Release`, due to the
-requirement of a specific interpreter. The exact details of this deprecation
-aren't too clear, see :ref:`pep-788-deprecation`.
+requirement of a specific interpreter. 
+
+The exact details of this deprecation aren't too clear. It's likely that
+the usual five-year deprecation (as specificed by :pep:`387`) will be too
+short, so for now, these functions will have no specific removal date.
 
 Specification
 =============
@@ -583,14 +585,25 @@ existing and new ``PyThreadState`` APIs. Namely:
   instead.
 
 All of the ``PyGILState`` APIs are to be removed from the non-limited C API in
-Python 3.25. They will remain available in the stable ABI for compatibility.
+a future Python version. They will remain available in the stable ABI for
+compatibility.
+
+It's worth noting that :c:func:`PyThreadState_Get` and
+:c:func:`PyThreadState_GetUnchecked` aren't perfect replacements for
+:c:func:`PyGILState_GetThisThreadState`, because
+:c:func:`PyGILState_GetThisThreadState` is able to return a thread state even
+when it is :term:`detached <attached thread state>`. This PEP intentionally
+doesn't leave a perfect replacement for this, because the GIL-state pointer
+(which holds the last used thread state by the thread) is only useful for
+those implementing :c:func:`PyThreadState_Ensure` or similar. It's not a
+common API to want as a user.
 
 Backwards Compatibility
 =======================
 
 This PEP specifies a breaking change with the removal of all the
-``PyGILState`` APIs from the public headers of the non-limited C API in 10
-years (Python 3.25).
+``PyGILState`` APIs from the public headers of the non-limited C API in a
+future version.
 
 Security Implications
 =====================
@@ -780,8 +793,9 @@ This is the same code, rewritten to use the new functions:
 Example: A Daemon Thread
 ************************
 
-Native daemon threads are still a use-case, and as such,
-they can still be used with this API:
+With this PEP, daemon threads are very similar to how native threads are used
+in the C API today. After calling :c:func:`PyThreadState_Ensure`, simply
+release the interpreter reference, allowing the interpreter to shut down.
 
 .. code-block:: c
 
@@ -1038,21 +1052,7 @@ under that category.
 Open Issues
 ===========
 
-.. _pep-788-deprecation:
-
-When Should the GIL-state APIs be Removed?
-------------------------------------------
-
-:c:func:`PyGILState_Ensure` and :c:func:`PyGILState_Release` have been around
-for over two decades, and it's expected that the migration will be difficult.
-Currently, the plan is to remove them in 10 years (opposed to the 5 years
-required by :pep:`387`), but this is subject to further discussion, as it's
-unclear if that's enough (or too much) time.
-
-In addition, it's unclear whether to remove them at all. A
-:term:`soft deprecation <soft deprecated>` could reasonably fit for these
-functions if it's determined that a full ``PyGILState`` removal would
-be too disruptive for the ecosystem.
+There are currently no open issues for this PEP.
 
 Copyright
 =========