Merge branch 'main' into bug/149501-fix-msvc-warning

Author: sergey-miryanov

.github/ISSUE_TEMPLATE/bug.yml

@@ -34,13 +34,13 @@ body:
       label: "CPython versions tested on:"
       multiple: true
       options:
-        - "3.9"
         - "3.10"
         - "3.11"
         - "3.12"
         - "3.13"
         - "3.14"
         - "3.15"
+        - "3.16"
         - "CPython main branch"
     validations:
       required: true

.github/ISSUE_TEMPLATE/crash.yml

@@ -27,13 +27,13 @@ body:
       label: "CPython versions tested on:"
       multiple: true
       options:
-        - "3.9"
         - "3.10"
         - "3.11"
         - "3.12"
         - "3.13"
         - "3.14"
         - "3.15"
+        - "3.16"
         - "CPython main branch"
     validations:
       required: true

Doc/c-api/exceptions.rst

@@ -1375,7 +1375,7 @@ Tracebacks
    The caller does not need to hold an :term:`attached thread state`, nor does
    *tstate* need to be attached.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 .. c:function:: const char* PyUnstable_DumpTracebackThreads(int fd, PyInterpreterState *interp, PyThreadState *current_tstate, Py_ssize_t max_threads)
 
@@ -1411,4 +1411,4 @@ Tracebacks
       another thread deletes its :term:`thread state` while this function is being
       called, the process will likely crash.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15

Doc/c-api/gcsupport.rst

@@ -414,7 +414,7 @@ In some cases, failure is not distinguishable from a successful ``NULL`` result.
 
    See :ref:`duringgc-functions` for common information.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
    .. seealso::
 
@@ -433,7 +433,7 @@ In some cases, failure is not distinguishable from a successful ``NULL`` result.
    The reference is valid for the duration
    of the :c:member:`!tp_traverse` handler call.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
    .. seealso:: :c:func:`PyType_GetBaseByToken`
 
@@ -445,7 +445,7 @@ In some cases, failure is not distinguishable from a successful ``NULL`` result.
    These functions return a :term:`borrowed reference`, which is
    valid for the duration of the :c:member:`!tp_traverse` handler call.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
    .. seealso::
 

Doc/c-api/interp-lifecycle.rst

@@ -410,7 +410,7 @@ Initializing and finalizing the interpreter
    (zero) if not.  After :c:func:`Py_FinalizeEx` is called, this returns false until
    :c:func:`Py_Initialize` is called again.
 
-   .. versionchanged:: next
+   .. versionchanged:: 3.15
       This function no longer returns true until initialization has fully
       completed, including import of the :mod:`site` module.  Previously it
       could return true while :c:func:`Py_Initialize` was still running.
@@ -631,7 +631,7 @@ it possible to avoid these issues by temporarily preventing finalization:
    automatically after all guards are released: it requires an explicit
    :c:func:`Py_EndInterpreter` call.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 
 .. c:function:: PyInterpreterGuard *PyInterpreterGuard_FromCurrent(void)
@@ -671,7 +671,7 @@ it possible to avoid these issues by temporarily preventing finalization:
 
    The caller must hold an :term:`attached thread state`.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 
 .. c:function:: PyInterpreterGuard *PyInterpreterGuard_FromView(PyInterpreterView *view)
@@ -688,7 +688,7 @@ it possible to avoid these issues by temporarily preventing finalization:
 
    The caller does not need to hold an :term:`attached thread state`.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 
 .. c:function:: void PyInterpreterGuard_Close(PyInterpreterGuard *guard)
@@ -705,7 +705,7 @@ it possible to avoid these issues by temporarily preventing finalization:
    This function cannot fail, and the caller doesn't need to hold an
    :term:`attached thread state`.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 
 .. _interpreter-views:
@@ -723,7 +723,7 @@ deleted. This can be done using interpreter views.
    This is a thread-safe way to access an interpreter that may have be
    finalizing or already destroyed.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 
 .. c:function:: PyInterpreterView *PyInterpreterView_FromCurrent(void)
@@ -738,7 +738,7 @@ deleted. This can be done using interpreter views.
 
    The caller must hold an :term:`attached thread state`.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 
 .. c:function:: void PyInterpreterView_Close(PyInterpreterView *view)
@@ -752,7 +752,7 @@ deleted. This can be done using interpreter views.
    This function cannot fail, and the caller doesn't need to hold an
    :term:`attached thread state`.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 
 .. c:function:: PyInterpreterView *PyInterpreterView_FromMain(void)
@@ -774,7 +774,7 @@ deleted. This can be done using interpreter views.
 
    The caller does not need to hold an :term:`attached thread state`.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 
 Process-wide parameters

Doc/c-api/module.rst

@@ -795,7 +795,7 @@ remove it.
    :c:macro:`Py_slot_subslots`, except it specifies an array of
    :c:type:`PyModuleDef_Slot` structures.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 .. _moduledef-dynamic:
 

Doc/c-api/sentinel.rst

@@ -10,14 +10,14 @@ Sentinel objects
    This instance of :c:type:`PyTypeObject` represents the Python
    :class:`sentinel` type.  This is the same object as :class:`sentinel`.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 .. c:function:: int PySentinel_Check(PyObject *o)
 
    Return true if *o* is a :class:`sentinel` object.  The :class:`sentinel` type
    does not allow subclasses, so this check is exact.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 .. c:function:: PyObject* PySentinel_New(const char *name, const char *module_name)
 
@@ -32,4 +32,4 @@ Sentinel objects
    path matching *name*.  Pickle treats *name* as a global variable name
    in *module_name* (see :meth:`object.__reduce__`).
 
-   .. versionadded:: next
+   .. versionadded:: 3.15

Doc/c-api/slots.rst

@@ -30,7 +30,7 @@ explicitly marked with :c:macro:`PySlot_STATIC`.
 Except when documented otherwise, multiple slots with the same ID
 (:c:member:`~PySlot.sl_id`) may not occur in a single slots array.
 
-.. versionadded:: next
+.. versionadded:: 3.15
 
    Slot arrays generalize an earlier way of defining objects:
    using :c:type:`PyType_Spec` with :c:type:`PyType_Slot` for types, and
@@ -125,7 +125,7 @@ Entries of the slots array use the following structure:
          Note that the "optionality" only applies to unknown slot IDs.
          This flag does not make Python skip invalid values of known slots.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 
 Convenience macros
@@ -169,7 +169,7 @@ Convenience macros
       #define PySlot_STATIC_DATA(NAME, VALUE) \
          {.sl_id=NAME, .sl_flags=PySlot_STATIC, .sl_ptr=(VALUE)}
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 .. c:macro:: PySlot_END
 
@@ -179,7 +179,7 @@ Convenience macros
 
       #define PySlot_END {0}
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 .. c:macro:: PySlot_PTR(name, value)
              PySlot_PTR_STATIC(name, value)
@@ -197,7 +197,7 @@ Convenience macros
       #define PySlot_PTR_STATIC(NAME, VALUE) \
          {NAME, PySlot_INTPTR|Py_SLOT_STATIC, {0}, {(void*)(VALUE)}}
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 .. _pyslot-common-ids:
 
@@ -211,7 +211,7 @@ The following slot IDs may be used in both type and module definitions.
    Marks the end of a slots array.
    Defined as zero.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 .. c:macro:: Py_slot_subslots
 
@@ -226,7 +226,7 @@ The following slot IDs may be used in both type and module definitions.
    Slot nesting depth is limited to 5 levels.
    This restriction may be lifted in the future.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 .. c:macro:: Py_slot_invalid
 
@@ -237,4 +237,4 @@ The following slot IDs may be used in both type and module definitions.
    no effect.
    Without the flag, processing a slot with this ID will fail.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15

Doc/c-api/stable.rst

@@ -74,7 +74,7 @@ There are two Stable ABIs:
   :term:`free-threaded <free-threaded build>` builds of CPython.
   It has stricter API limitations than ``abi3``.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
       ``abi3t`` was added in :pep:`803`
 
@@ -170,7 +170,7 @@ both Stable ABIs.
    :term:`free-threaded builds <free-threaded build>` of CPython.
    See :ref:`above <abi3-compiling>` for common information.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 Both macros specify a target ABI; the different naming style is due to
 backwards compatibility.

Doc/c-api/threads.rst

@@ -296,7 +296,7 @@ Attaching/detaching thread states
       Otherwise, if both of the above cases fail, a new thread state is created
       for *guard*. It is then attached and marked as owned by ``PyThreadState_Ensure``.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 
 .. c:function:: PyThreadStateToken *PyThreadState_EnsureFromView(PyInterpreterView *view)
@@ -308,7 +308,7 @@ Attaching/detaching thread states
    be implicitly guarded. The guard will be released upon the corresponding
    :c:func:`PyThreadState_Release` call.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 
 .. c:function:: void PyThreadState_Release(PyThreadStateToken *token)
@@ -335,7 +335,7 @@ Attaching/detaching thread states
       attached thread state will be deallocated and deleted upon the internal counter
       reaching zero. Otherwise, nothing happens when the counter reaches zero.
 
-   .. versionadded:: next
+   .. versionadded:: 3.15
 
 .. c:type:: PyThreadStateToken