Merge branch 'main' into gh-151556

Author: lul-cas

.github/workflows/jit.yml

@@ -64,10 +64,10 @@ jobs:
         include:
           - target: i686-pc-windows-msvc/msvc
             architecture: Win32
-            runner: windows-2025-vs2026
+            runner: windows-2025
           - target: x86_64-pc-windows-msvc/msvc
             architecture: x64
-            runner: windows-2025-vs2026
+            runner: windows-2025
           - target: aarch64-pc-windows-msvc/msvc
             architecture: ARM64
             runner: windows-11-arm
@@ -183,6 +183,9 @@ jobs:
           - name: JIT without optimizations (Debug)
             configure_flags: --enable-experimental-jit --with-pydebug
             test_env: "PYTHON_UOPS_OPTIMIZE=0"
+          - name: JIT with stress testing (Debug)
+            configure_flags: --enable-experimental-jit --with-pydebug
+            test_env: "PYTHON_JIT_STRESS=1"
           - name: JIT with tail calling interpreter
             configure_flags: --enable-experimental-jit --with-tail-call-interp --with-pydebug
             use_clang: true

.github/workflows/reusable-windows-msi.yml

@@ -17,7 +17,7 @@ env:
 jobs:
   build:
     name: installer for ${{ inputs.arch }}
-    runs-on: ${{ inputs.arch == 'arm64' && 'windows-11-arm' || 'windows-2025-vs2026' }}
+    runs-on: ${{ inputs.arch == 'arm64' && 'windows-11-arm' || 'windows-2025' }}
     timeout-minutes: 60
     env:
       ARCH: ${{ inputs.arch }}

.github/workflows/reusable-windows.yml

@@ -26,7 +26,7 @@ env:
 jobs:
   build:
     name: Build and test (${{ inputs.arch }}, ${{ inputs.interpreter }})
-    runs-on: ${{ inputs.arch == 'arm64' && 'windows-11-arm' || 'windows-2025-vs2026' }}
+    runs-on: ${{ inputs.arch == 'arm64' && 'windows-11-arm' || 'windows-2025' }}
     timeout-minutes: 60
     env:
       ARCH: ${{ inputs.arch }}

.readthedocs.yml

@@ -11,19 +11,21 @@ build:
   os: ubuntu-24.04
   tools:
     python: "3"
+  apt_packages:
+    - jq
 
   jobs:
-    post_checkout:
+    post_system_dependencies:
       # https://docs.readthedocs.com/platform/stable/guides/build/skip-build.html#skip-builds-based-on-conditions
       #
-      # Cancel building pull requests when there aren't changes in the Doc
+      # Cancel building pull requests when there are no changes in the Doc
       # directory or RTD configuration, or if we can't cleanly merge the base
       # branch.
       - |
         set -eEux;
         if [ "$READTHEDOCS_VERSION_TYPE" = "external" ];
         then
-          base_branch=main;
+          base_branch=$(wget -qO- "https://api.github.com/repos/python/cpython/pulls/$READTHEDOCS_VERSION" | jq -er ".base.ref");
           git fetch --depth=50 origin $base_branch:origin-$base_branch;
           for attempt in $(seq 10);
           do

Doc/c-api/bytes.rst

@@ -384,14 +384,18 @@ Getters
 
    Get the writer size.
 
+   The function does not invalidate pointers returned by
+   :c:func:`PyBytesWriter_GetData`.
+
    The function cannot fail.
 
 .. c:function:: void* PyBytesWriter_GetData(PyBytesWriter *writer)
 
    Get the writer data: start of the internal buffer.
 
-   The pointer is valid until :c:func:`PyBytesWriter_Finish` or
-   :c:func:`PyBytesWriter_Discard` is called on *writer*.
+   The pointer remains valid until a :c:type:`PyBytesWriter` function other
+   than :c:func:`PyBytesWriter_GetData` or :c:func:`PyBytesWriter_GetSize` is
+   called on *writer*.
 
    The function cannot fail.
 

Doc/c-api/type.rst

@@ -563,10 +563,10 @@ but need extra remarks for use as slots:
    :c:member:`Slot ID <PySlot.sl_id>` for the name of the type,
    used to set :c:member:`PyTypeObject.tp_name`.
 
-   This slot (or :c:func:`PyType_Spec.name`) is required to create a type.
+   This slot (or :c:member:`PyType_Spec.name`) is required to create a type.
 
    This may not be used in :c:member:`PyType_Spec.slots`.
-   Use :c:func:`PyType_Spec.name` instead.
+   Use :c:member:`PyType_Spec.name` instead.
 
    .. impl-detail::
 
@@ -585,7 +585,7 @@ but need extra remarks for use as slots:
    The value must be positive.
 
    This may not be used in :c:member:`PyType_Spec.slots`.
-   Use :c:func:`PyType_Spec.basicsize` instead.
+   Use :c:member:`PyType_Spec.basicsize` instead.
 
    This slot may not be used with :c:func:`PyType_GetSlot`.
    Use :c:member:`PyTypeObject.tp_basicsize` instead if needed, but be aware
@@ -616,7 +616,7 @@ but need extra remarks for use as slots:
    :c:macro:`!Py_tp_extra_basicsize` is an error.
 
    This may not be used in :c:member:`PyType_Spec.slots`.
-   Use negative :c:func:`PyType_Spec.basicsize` instead.
+   Use negative :c:member:`PyType_Spec.basicsize` instead.
 
    This slot may not be used with :c:func:`PyType_GetSlot`.
 
@@ -648,7 +648,7 @@ but need extra remarks for use as slots:
    - With the :c:macro:`Py_TPFLAGS_ITEMS_AT_END` flag.
 
    This may not be used in :c:member:`PyType_Spec.slots`.
-   Use :c:func:`PyType_Spec.itemsize` instead.
+   Use :c:member:`PyType_Spec.itemsize` instead.
 
    This slot may not be used with :c:func:`PyType_GetSlot`.
 
@@ -663,13 +663,44 @@ but need extra remarks for use as slots:
    :c:func:`PyType_FromSpecWithBases` sets it automatically.
 
    This may not be used in :c:member:`PyType_Spec.slots`.
-   Use negative :c:func:`PyType_Spec.basicsize` instead.
+   Use negative :c:member:`PyType_Spec.basicsize` instead.
 
    This slot may not be used with :c:func:`PyType_GetSlot`.
    Use :c:func:`PyType_GetFlags` instead.
 
    .. versionadded:: 3.15
 
+.. c:macro:: Py_tp_bases
+
+   :c:member:`Slot ID <PySlot.sl_id>` for type flags, used to set
+   :c:member:`PyTypeObject.tp_bases`.
+
+   The slot can be set to a tuple of type objects which the newly created
+   type should inherit from, like the "positional arguments" of
+   a Python :ref:`class definition <class>`.
+
+   Alternately, the slot can be set to a single type object to specify
+   a single base.
+   The effect is the same as specifying a one-element tuple.
+
+   .. versionchanged:: 3.15
+
+      Previously, :c:macro:`!Py_tp_bases` required a tuple of types.
+
+.. c:macro:: Py_tp_base
+
+   Equivalent to :c:macro:`Py_tp_bases` (with ``s`` at the end).
+   If both are specified, :c:macro:`!Py_tp_bases` takes priority and
+   this slot is ignored.
+
+   .. versionchanged:: 3.15
+
+      Previously, :c:macro:`!Py_tp_base` required a single type, not a tuple.
+
+   .. soft-deprecated:: 3.15
+
+      When not targetting older Python versions, pefer :c:macro:`!Py_tp_bases`.
+
 The following slots do not correspond to public fields in the
 underlying structures:
 

Doc/c-api/typeobj.rst

@@ -1936,12 +1936,12 @@ and :c:data:`PyType_Type` effectively act as defaults.)
 
 .. c:member:: PyTypeObject* PyTypeObject.tp_base
 
-   .. corresponding-type-slot:: Py_tp_base
-
    An optional pointer to a base type from which type properties are inherited.  At
    this level, only single inheritance is supported; multiple inheritance require
    dynamically creating a type object by calling the metatype.
 
+   For the corresponding slot ID, see :c:macro:`Py_tp_base`.
+
    .. note::
 
        .. from Modules/xxmodule.c
@@ -2253,17 +2253,12 @@ and :c:data:`PyType_Type` effectively act as defaults.)
 
 .. c:member:: PyObject* PyTypeObject.tp_bases
 
-   .. corresponding-type-slot:: Py_tp_bases
-
    Tuple of base types.
 
    This field should be set to ``NULL`` and treated as read-only.
    Python will fill it in when the type is :c:func:`initialized <PyType_Ready>`.
 
-   For dynamically created classes, the :c:data:`Py_tp_bases`
-   :c:type:`slot <PyType_Slot>` can be used instead of the *bases* argument
-   of :c:func:`PyType_FromSpecWithBases`.
-   The argument form is preferred.
+   For the corresponding slot ID, see :c:macro:`Py_tp_bases`.
 
    .. warning::
 

Doc/deprecations/index.rst

@@ -1,8 +1,6 @@
 Deprecations
 ============
 
-.. include:: pending-removal-in-3.16.rst
-
 .. include:: pending-removal-in-3.17.rst
 
 .. include:: pending-removal-in-3.18.rst
@@ -20,8 +18,6 @@ Deprecations
 C API deprecations
 ------------------
 
-.. include:: c-api-pending-removal-in-3.16.rst
-
 .. include:: c-api-pending-removal-in-3.18.rst
 
 .. include:: c-api-pending-removal-in-3.19.rst

Doc/extending/extending.rst

@@ -231,10 +231,8 @@ calling the Python callback functions from a C callback.  Other uses are also
 imaginable.
 
 Fortunately, the Python interpreter is easily called recursively, and there is a
-standard interface to call a Python function.  (I won't dwell on how to call the
-Python parser with a particular string as input --- if you're interested, have a
-look at the implementation of the :option:`-c` command line option in
-:file:`Modules/main.c` from the Python source code.)
+standard interface to call a Python function.  (If you're interested in how to call the
+Python parser with a particular string as input, see :ref:`veryhigh`.)
 
 Calling a Python function is easy.  First, the Python program must somehow pass
 you the Python function object.  You should provide a function (or some other
@@ -641,7 +639,7 @@ and the object is freed.
 
 An alternative strategy is called :dfn:`automatic garbage collection`.
 (Sometimes, reference counting is also referred to as a garbage collection
-strategy, hence my use of "automatic" to distinguish the two.)  The big
+strategy, hence the use of "automatic" to distinguish the two.)  The big
 advantage of automatic garbage collection is that the user doesn't need to call
 :c:func:`free` explicitly.  (Another claimed advantage is an improvement in speed
 or memory usage --- this is no hard fact however.)  The disadvantage is that for

Doc/glossary.rst

@@ -96,21 +96,24 @@ Glossary
       :meth:`~object.__aexit__` methods.  Introduced by :pep:`492`.
 
    asynchronous generator
-      A function which returns an :term:`asynchronous generator iterator`.  It
-      looks like a coroutine function defined with :keyword:`async def` except
-      that it contains :keyword:`yield` expressions for producing a series of
-      values usable in an :keyword:`async for` loop.
-
-      Usually refers to an asynchronous generator function, but may refer to an
-      *asynchronous generator iterator* in some contexts.  In cases where the
-      intended meaning isn't clear, using the full terms avoids ambiguity.
+      Informally used to mean either an :term:`asynchronous generator
+      function` or an :term:`asynchronous generator iterator`, depending on
+      context.  The formal terms :term:`asynchronous generator function` and
+      :term:`asynchronous generator iterator` are uncommon in practice;
+      "asynchronous generator" alone is almost always sufficient.
+
+   asynchronous generator function
+      A function which returns an :term:`asynchronous generator iterator`.
+      It looks like a coroutine function defined with :keyword:`async def`
+      except that it contains :keyword:`yield` expressions for producing a
+      series of values usable in an :keyword:`async for` loop.  See :pep:`525`.
 
       An asynchronous generator function may contain :keyword:`await`
       expressions as well as :keyword:`async for`, and :keyword:`async with`
       statements.
 
    asynchronous generator iterator
-      An object created by an :term:`asynchronous generator` function.
+      An object created by an :term:`asynchronous generator function`.
 
       This is an :term:`asynchronous iterator` which when called using the
       :meth:`~object.__anext__` method returns an awaitable object which will execute
@@ -641,23 +644,33 @@ Glossary
       .. index:: single: generator
 
    generator
-      A function which returns a :term:`generator iterator`.  It looks like a
-      normal function except that it contains :keyword:`yield` expressions
-      for producing a series of values usable in a for-loop or that can be
-      retrieved one at a time with the :func:`next` function.
+      Informally used to mean either a :term:`generator function` or a
+      :term:`generator iterator`, depending on context.  The formal terms
+      :term:`generator function` and :term:`generator iterator` are uncommon
+      in practice; "generator" alone is almost always sufficient.
 
-      Usually refers to a generator function, but may refer to a
-      *generator iterator* in some contexts.  In cases where the intended
-      meaning isn't clear, using the full terms avoids ambiguity.
+      .. index:: single: generator function
+
+   generator function
+      A function which returns a :term:`generator` object.  It looks like a
+      normal function except that it contains :keyword:`yield` expressions
+      for producing a series of values usable in a :keyword:`for`\-loop or
+      that can be retrieved one at a time with the :func:`next` function.
+      See :ref:`yieldexpr`.
 
    generator iterator
-      An object created by a :term:`generator` function.
+      An object created by a :term:`generator function` or a
+      :term:`generator expression`.
 
       Each :keyword:`yield` temporarily suspends processing, remembering the
-      execution state (including local variables and pending
-      try-statements).  When the *generator iterator* resumes, it picks up where
-      it left off (in contrast to functions which start fresh on every
-      invocation).
+      execution state (including local variables and pending try-statements).
+      When the *generator iterator* resumes, it picks up where it left off
+      (in contrast to functions which start fresh on every invocation).
+
+      Generator iterators also implement the :meth:`~generator.send` method
+      to send a value into the suspended generator, and the
+      :meth:`~generator.throw` method to raise an exception at the point
+      where the generator was paused.  See :ref:`generator-methods`.
 
       .. index:: single: generator expression