Merge branch 'main' into gh-152107

Author: sergey-miryanov

.github/workflows/reusable-emscripten.yml

@@ -63,15 +63,17 @@ jobs:
       run: python3 Platforms/emscripten configure-build-python -- --config-cache --with-pydebug
     - name: "Make build Python"
       run: python3 Platforms/emscripten make-build-python
+    - name: "Display build info of the build Python"
+      run: python3 Platforms/emscripten pythoninfo-build
     - name: "Make dependencies"
       run: >-
         python3 Platforms/emscripten make-dependencies
         ${{ steps.emsdk-cache.outputs.cache-hit == 'true' && '--check-up-to-date' || '' }}
-    - name: "Configure host Python"
+    - name: "Configure host/Emscripten Python"
       run: python3 Platforms/emscripten configure-host --host-runner node -- --config-cache
-    - name: "Make host Python"
+    - name: "Make host/Emscripten Python"
       run: python3 Platforms/emscripten make-host
-    - name: "Display build info"
-      run: python3 Platforms/emscripten run --pythoninfo
+    - name: "Display build info of the host/Emscripten Python"
+      run: python3 Platforms/emscripten pythoninfo-host
     - name: "Test"
       run: python3 Platforms/emscripten run --test

.github/workflows/reusable-wasi.yml

@@ -16,7 +16,6 @@ jobs:
     timeout-minutes: 60
     env:
       WASMTIME_VERSION: 38.0.3
-      CROSS_BUILD_PYTHON: cross-build/build
       CROSS_BUILD_WASI: cross-build/wasm32-wasip1
     steps:
     - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
@@ -54,14 +53,16 @@ jobs:
       run: python3 Platforms/WASI configure-build-python -- --config-cache --with-pydebug
     - name: "Make build Python"
       run: python3 Platforms/WASI make-build-python
-    - name: "Configure host"
+    - name: "Display build info of the build Python"
+      run: python3 Platforms/WASI pythoninfo-build
+    - name: "Configure host/WASI Python"
       # `--with-pydebug` inferred from configure-build-python
       run: python3 Platforms/WASI configure-host -- --config-cache
       env:
         WASI_SDK_PATH: ${{ steps.install-wasi-sdk.outputs.wasi-sdk-path }}
-    - name: "Make host"
+    - name: "Make host/WASI Python"
       run: python3 Platforms/WASI make-host
-    - name: "Display build info"
-      run: make --directory "${CROSS_BUILD_WASI}" pythoninfo
+    - name: "Display build info of the host/WASI Python"
+      run: python3 Platforms/WASI pythoninfo-host
     - name: "Test"
       run: make --directory "${CROSS_BUILD_WASI}" test

Doc/c-api/type.rst

@@ -639,7 +639,7 @@ but need extra remarks for use as slots:
    in the following situations:
 
    - The base is not variable-sized (its
-     :c:member:`~PyTypeObject.tp_itemsize`).
+     :c:member:`~PyTypeObject.tp_itemsize` is zero).
    - The requested :c:member:`PyType_Spec.basicsize` is positive,
      suggesting that the memory layout of the base class is known.
    - The requested :c:member:`PyType_Spec.basicsize` is zero,

Doc/deprecations/pending-removal-in-3.16.rst

@@ -33,12 +33,12 @@ Pending removal in Python 3.16
   * :mod:`asyncio` policy system is deprecated and will be removed in Python 3.16.
     In particular, the following classes and functions are deprecated:
 
-    * :class:`asyncio.AbstractEventLoopPolicy`
-    * :class:`asyncio.DefaultEventLoopPolicy`
-    * :class:`asyncio.WindowsSelectorEventLoopPolicy`
-    * :class:`asyncio.WindowsProactorEventLoopPolicy`
-    * :func:`asyncio.get_event_loop_policy`
-    * :func:`asyncio.set_event_loop_policy`
+    * :class:`!asyncio.AbstractEventLoopPolicy`
+    * :class:`!asyncio.DefaultEventLoopPolicy`
+    * :class:`!asyncio.WindowsSelectorEventLoopPolicy`
+    * :class:`!asyncio.WindowsProactorEventLoopPolicy`
+    * :func:`!asyncio.get_event_loop_policy`
+    * :func:`!asyncio.set_event_loop_policy`
 
     Users should use :func:`asyncio.run` or :class:`asyncio.Runner` with
     *loop_factory* to use the desired event loop implementation.

Doc/deprecations/pending-removal-in-3.17.rst

@@ -68,3 +68,13 @@ Pending removal in Python 3.17
 
     See :pep:`PEP 688 <688#current-options>` for more details.
     (Contributed by Shantanu Jain in :gh:`91896`.)
+
+* :mod:`tkinter`:
+
+  - The :class:`!tkinter.Variable` methods :meth:`!trace_variable`,
+    :meth:`!trace` (an alias of :meth:`!trace_variable`),
+    :meth:`!trace_vdelete` and :meth:`!trace_vinfo`, deprecated since
+    Python 3.14, are scheduled for removal in Python 3.17.
+    Use :meth:`!trace_add`, :meth:`!trace_remove` and :meth:`!trace_info`
+    instead.
+    (Contributed by Serhiy Storchaka in :gh:`120220`.)

Doc/deprecations/soft-deprecations.rst

@@ -19,3 +19,8 @@ There are no plans to remove :term:`soft deprecated` APIs.
 
   (Contributed by Gregory P. Smith in :gh:`86519` and
   Hugo van Kemenade in :gh:`148100`.)
+
+* Using ``'F'`` and ``'D'`` format type codes of the :mod:`struct` module
+  now are :term:`soft deprecated` in favor of two-letter forms ``'Zf'``
+  and ``'Zd'``.
+  (Contributed by Sergey B Kirpichev in :gh:`121249`.)

Doc/library/asyncio-eventloop.rst

@@ -48,10 +48,10 @@ an event loop:
    running event loop.
 
    If there is no running event loop set, the function will return
-   the result of the ``get_event_loop_policy().get_event_loop()`` call.
+   the loop set by :func:`set_event_loop`, or raise a :exc:`RuntimeError`
+   if no loop has been set.
 
-   Because this function has rather complex behavior (especially
-   when custom event loop policies are in use), using the
+   Because this function has rather complex behavior, using the
    :func:`get_running_loop` function is preferred to :func:`get_event_loop`
    in coroutines and callbacks.
 
@@ -62,13 +62,6 @@ an event loop:
    .. versionchanged:: 3.14
       Raises a :exc:`RuntimeError` if there is no current event loop.
 
-   .. note::
-
-      The :mod:`!asyncio` policy system is deprecated and will be removed
-      in Python 3.16; from there on, this function will return the current
-      running event loop if present else it will return the
-      loop set by :func:`set_event_loop`.
-
 .. function:: set_event_loop(loop)
 
    Set *loop* as the current event loop for the current OS thread.
@@ -77,10 +70,6 @@ an event loop:
 
    Create and return a new event loop object.
 
-Note that the behaviour of :func:`get_event_loop`, :func:`set_event_loop`,
-and :func:`new_event_loop` functions can be altered by
-:ref:`setting a custom event loop policy <asyncio-policies>`.
-
 
 .. rubric:: Contents
 

Doc/library/asyncio-llapi-index.rst

@@ -19,10 +19,10 @@ Obtaining the Event Loop
       - The **preferred** function to get the running event loop.
 
     * - :func:`asyncio.get_event_loop`
-      - Get an event loop instance (running or current via the current policy).
+      - Get the running event loop or the event loop set for the current thread.
 
     * - :func:`asyncio.set_event_loop`
-      - Set the event loop as current via the current policy.
+      - Set the event loop for the current thread.
 
     * - :func:`asyncio.new_event_loop`
       - Create a new event loop.
@@ -497,27 +497,3 @@ Protocol classes can implement the following **callback methods**:
       - Called when the child process has exited. It can be called before
         :meth:`~SubprocessProtocol.pipe_data_received` and
         :meth:`~SubprocessProtocol.pipe_connection_lost` methods.
-
-
-Event Loop Policies
-===================
-
-Policies is a low-level mechanism to alter the behavior of
-functions like :func:`asyncio.get_event_loop`.  See also
-the main :ref:`policies section <asyncio-policies>` for more
-details.
-
-
-.. rubric:: Accessing Policies
-.. list-table::
-    :widths: 50 50
-    :class: full-width-table
-
-    * - :meth:`asyncio.get_event_loop_policy`
-      - Return the current process-wide policy.
-
-    * - :meth:`asyncio.set_event_loop_policy`
-      - Set a new process-wide policy.
-
-    * - :class:`AbstractEventLoopPolicy`
-      - Base class for policy objects.

Doc/library/asyncio-policy.rst

@@ -43,9 +43,7 @@ Running an asyncio Program
    otherwise :func:`asyncio.new_event_loop` is used. The loop is closed at the end.
    This function should be used as a main entry point for asyncio programs,
    and should ideally only be called once. It is recommended to use
-   *loop_factory* to configure the event loop instead of policies.
-   Passing :class:`asyncio.EventLoop` allows running asyncio without the
-   policy system.
+   *loop_factory* to configure the event loop.
 
    The executor is given a timeout duration of 5 minutes to shutdown.
    If the executor hasn't finished within that duration, a warning is
@@ -76,12 +74,6 @@ Running an asyncio Program
 
       *coro* can be any awaitable object.
 
-   .. note::
-
-      The :mod:`!asyncio` policy system is deprecated and will be removed
-      in Python 3.16; from there on, an explicit *loop_factory* is needed
-      to configure the event loop.
-
 
 Runner context manager
 ======================