Fix lint and remove dead comment.

ZeroIntensity · May 6, 2026 · Apr 28, 2026 · Apr 28, 2026 · Apr 28, 2026 · Apr 28, 2026
commit 74259f8c2ebeb017d11c18c00a3660a8a9b45529
@@ -608,8 +608,8 @@ it possible to avoid these issues by temporarily preventing finalization:
 
 .. seealso::
 
-   :pep:`788` explains the design, motivation and rationale
-   for these APIs.
+   :pep:`788` explains the design, motivation and rationale
+   for these APIs.
 
 .. c:type:: PyInterpreterGuard
 
@@ -625,19 +625,19 @@ it possible to avoid these issues by temporarily preventing finalization:
    guards for that interpreter. This means that if you forget to close an
    interpreter guard, the process will **permanently hang** during
    finalization!
-
-   Holding a guard for an interpreter is similar to holding a
-   :term:`strong reference` to a Python object, except finalization does not happen
-   automatically after all guards are released: it requires an explicit 
-   :c:func:`Py_EndInterpreter` call.
-
+
+   Holding a guard for an interpreter is similar to holding a
+   :term:`strong reference` to a Python object, except finalization does not happen
+   automatically after all guards are released: it requires an explicit 
+   :c:func:`Py_EndInterpreter` call.
+
    .. versionadded:: next
 
 
 .. c:function:: PyInterpreterGuard *PyInterpreterGuard_FromCurrent(void)
 
    Create a finalization guard for the current interpreter. This will prevent
-   finalization until the guard is closed.
+   finalization until the guard is closed.
 
    For example:
 
@@ -770,8 +770,8 @@ deleted. This can be done using interpreter views.
    Failure indicates that the process is out of memory or that the main
    interpreter has finalized (or never existed).
 
-   Using this function in extension libraries is strongly discouraged, because
-   it typically compromises the library's subinterpreter support. It exists
+   Using this function in extension libraries is strongly discouraged, because
+   it typically compromises the library's subinterpreter support. It exists
    for exceptional cases where there is no other option (such as when a native
    threading library doesn't provide a ``void *arg`` parameter that could be
    used to store a ``PyInterpreterGuard`` or ``PyInterpreterView`` pointer).