Merge branch 'main' into jit_record_family

Author: cocolato

.github/workflows/build.yml

@@ -283,6 +283,7 @@ jobs:
           - { name: openssl, version: 3.4.5 }
           - { name: openssl, version: 3.5.6 }
           - { name: openssl, version: 3.6.2 }
+          - { name: openssl, version: 4.0.0 }
           ## AWS-LC
           - { name: aws-lc, version: 1.72.1 }
     env:

Doc/c-api/synchronization.rst

@@ -84,11 +84,6 @@ there is no :c:type:`PyObject` -- for example, when working with a C type that
 does not extend or wrap :c:type:`PyObject` but still needs to call into the C
 API in a manner that might lead to deadlocks.
 
-The functions and structs used by the macros are exposed for cases
-where C macros are not available. They should only be used as in the
-given macro expansions. Note that the sizes and contents of the structures may
-change in future Python versions.
-
 .. note::
 
    Operations that need to lock two objects at once must use
@@ -114,12 +109,15 @@ section API avoids potential deadlocks due to reentrancy and lock ordering
 by allowing the runtime to temporarily suspend the critical section if the
 code triggered by the finalizer blocks and calls :c:func:`PyEval_SaveThread`.
 
+.. _critical-section-macros:
+
 .. c:macro:: Py_BEGIN_CRITICAL_SECTION(op)
 
    Acquires the per-object lock for the object *op* and begins a
    critical section.
 
-   In the free-threaded build, this macro expands to::
+   In the free-threaded build, and when building for the
+   :ref:`Stable ABI <stable-abi>`, this macro expands to::
 
       {
           PyCriticalSection _py_cs;
@@ -150,7 +148,8 @@ code triggered by the finalizer blocks and calls :c:func:`PyEval_SaveThread`.
 
    Ends the critical section and releases the per-object lock.
 
-   In the free-threaded build, this macro expands to::
+   In the free-threaded build, and when building for the
+   :ref:`Stable ABI <stable-abi>`, this macro expands to::
 
           PyCriticalSection_End(&_py_cs);
       }
@@ -179,7 +178,8 @@ code triggered by the finalizer blocks and calls :c:func:`PyEval_SaveThread`.
 
    Locks the mutexes *m1* and *m2* and begins a critical section.
 
-   In the free-threaded build, this macro expands to::
+   In the free-threaded build, and when building for the
+   :ref:`Stable ABI <stable-abi>`, this macro expands to::
 
      {
           PyCriticalSection2 _py_cs2;
@@ -196,7 +196,8 @@ code triggered by the finalizer blocks and calls :c:func:`PyEval_SaveThread`.
 
    Ends the critical section and releases the per-object locks.
 
-   In the free-threaded build, this macro expands to::
+   In the free-threaded build, and when building for the
+   :ref:`Stable ABI <stable-abi>`, this macro expands to::
 
           PyCriticalSection2_End(&_py_cs2);
       }
@@ -205,6 +206,48 @@ code triggered by the finalizer blocks and calls :c:func:`PyEval_SaveThread`.
 
    .. versionadded:: 3.13
 
+Low-level critical section API
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The following functions and structs are exposed for cases where C macros
+are not available.
+
+.. c:function:: void PyCriticalSection_Begin(PyCriticalSection *c, PyObject *op)
+                void PyCriticalSection_End(PyCriticalSection *c)
+                void PyCriticalSection2_Begin(PyCriticalSection2 *c, PyObject *a, PyObject *b)
+                void PyCriticalSection2_End(PyCriticalSection2 *c);
+
+   To be used only as in the macro expansions
+   listed :ref:`earlier in this section <critical-section-macros>`.
+
+   In non-:term:`free-threaded <free threading>` builds of CPython, these
+   functions do nothing.
+
+   .. versionadded:: 3.13
+
+.. c:type:: PyCriticalSection
+            PyCriticalSection2
+
+   To be used only as in the macro expansions
+   listed :ref:`earlier in this section <critical-section-macros>`.
+   Note that the contents of the structures are private and their meaning may
+   change in future Python versions.
+
+   .. versionadded:: 3.13
+
+.. c:function:: void PyCriticalSection_BeginMutex(PyCriticalSection *c, PyMutex *m);
+                void PyCriticalSection2_BeginMutex(PyCriticalSection2 *c, PyMutex *m1, PyMutex *m2);
+
+   .. (These need to be in a separate section without a Stable ABI anotation.)
+
+   To be used only as in the macro expansions
+   listed :ref:`earlier in this section <critical-section-macros>`.
+
+   In non-:term:`free-threaded <free threading>` builds of CPython, these
+   functions do nothing.
+
+   .. versionadded:: 3.14
+
 
 Legacy locking APIs
 -------------------

Doc/data/stable_abi.dat

@@ -637,25 +637,22 @@ are set.
 
 .. versionadded:: 3.14
 
-To highlight inline code in your description or epilog text, you can use
-backticks::
+To highlight inline code in your description, epilog, or argument ``help``
+text, you can use single or double backticks::
 
    >>> parser = argparse.ArgumentParser(
    ...     formatter_class=argparse.RawDescriptionHelpFormatter,
+   ...     description='Run ``python -m myapp`` to start.',
    ...     epilog='''Examples:
    ...   `python -m myapp --verbose`
-   ...   `python -m myapp --config settings.json`
+   ...   ``python -m myapp --config settings.json``
    ... ''')
+   >>> parser.add_argument('--foo', help='set the `foo` value')
 
 When colors are enabled, the text inside backticks will be displayed in a
 distinct color to help examples stand out. When colors are disabled, backticks
 are preserved as-is, which is readable in plain text.
 
-.. note::
-
-   Backtick markup only applies to description and epilog text. It does not
-   apply to individual argument ``help`` strings.
-
 .. versionadded:: 3.15
 
 

Doc/library/argparse.rst

@@ -48,9 +48,9 @@ defined:
 +-----------+--------------------+-------------------+-----------------------+-------+
 | ``'d'``   | double             | float             | 8                     |       |
 +-----------+--------------------+-------------------+-----------------------+-------+
-| ``'F'``   | float complex      | complex           | 8                     | \(4)  |
+| ``'Zf'``  | float complex      | complex           | 8                     | \(4)  |
 +-----------+--------------------+-------------------+-----------------------+-------+
-| ``'D'``   | double complex     | complex           | 16                    | \(4)  |
+| ``'Zd'``  | double complex     | complex           | 16                    | \(4)  |
 +-----------+--------------------+-------------------+-----------------------+-------+
 
 
@@ -80,7 +80,7 @@ Notes:
    .. versionadded:: 3.15
 
 (4)
-   Complex types (``F`` and ``D``) are available unconditionally,
+   Complex types (``Zf`` and ``Zd``) are available unconditionally,
    regardless on support for complex types (the Annex G of the C11 standard)
    by the C compiler.
    As specified in the C11 standard, each complex type is represented by a
@@ -105,7 +105,10 @@ The module defines the following item:
 
 .. data:: typecodes
 
-   A string with all available type codes.
+   A tuple with all available type codes.
+
+   .. versionchanged:: next
+      The type changed from :class:`str` to :class:`tuple`.
 
 
 The module defines the following type:

Doc/library/array.rst

@@ -756,6 +756,11 @@ The following options are accepted:
    By default, today's date is highlighted in color and can be
    :ref:`controlled using environment variables <using-on-controlling-color>`.
 
+.. versionchanged:: next
+   By default, the month is now also highlighted in color, and
+   the days of the week are also in color. This behavior can be
+   :ref:`controlled using environment variables <using-on-controlling-color>`.
+
 *HTML-mode options:*
 
 .. option:: --css CSS, -c CSS

Doc/library/calendar.rst

@@ -370,15 +370,19 @@ in both C and ``libffi``, the following complex types are available:
    * - :class:`c_float_complex`
      - :c:expr:`float complex`
      - :py:class:`complex`
-     - ``'F'``
+     - ``'Zf'``
    * - :class:`c_double_complex`
      - :c:expr:`double complex`
      - :py:class:`complex`
-     - ``'D'``
+     - ``'Zd'``
    * - :class:`c_longdouble_complex`
      - :c:expr:`long double complex`
      - :py:class:`complex`
-     - ``'G'``
+     - ``'Zg'``
+
+.. versionchanged:: next
+   The :py:attr:`~_SimpleCData._type_` types ``F``, ``D`` and ``G`` have been
+   replaced with ``Zf``, ``Zd`` and ``Zg``.
 
 
 All these types can be created by calling them with an optional initializer of

Doc/library/ctypes.rst

@@ -1833,8 +1833,15 @@ from the command line.
 
 By default, accepts the name of a module and prints the source of that
 module. A class or function within the module can be printed instead by
-appended a colon and the qualified name of the target object.
+appending a colon and the qualified name of the target object.
 
 .. option:: --details
 
    Print information about the specified object rather than the source code
+
+.. versionchanged:: next
+
+   The ``--details`` option now supports basic introspection for modules
+   without available source code and indicates when modules are frozen.
+   It also indicates when the given target reference is not the canonical
+   name of the referenced object.

Doc/library/inspect.rst

@@ -367,9 +367,9 @@ write code that handles both IP versions correctly.  Address objects are
 
    .. attribute:: ipv4_mapped
 
-      For addresses that appear to be IPv4 mapped addresses (starting with
-      ``::FFFF/96``), this property will report the embedded IPv4 address.
-      For any other address, this property will be ``None``.
+      For addresses that appear to be IPv4 mapped addresses in the range
+      ``::FFFF:0:0/96`` as defined by :RFC:`4291`, this property reports the
+      embedded IPv4 address. For any other address, this property will be ``None``.
 
    .. attribute:: scope_id
 

Doc/library/ipaddress.rst

@@ -264,6 +264,10 @@ platform-dependent.
 +--------+--------------------------+--------------------+----------------+------------+
 | ``D``  | :c:expr:`double complex` | complex            | 16             | \(10)      |
 +--------+--------------------------+--------------------+----------------+------------+
+| ``Zf`` | :c:expr:`float complex`  | complex            | 8              | \(10)      |
++--------+--------------------------+--------------------+----------------+------------+
+| ``Zd`` | :c:expr:`double complex` | complex            | 16             | \(10)      |
++--------+--------------------------+--------------------+----------------+------------+
 | ``s``  | :c:expr:`char[]`         | bytes              |                | \(9)       |
 +--------+--------------------------+--------------------+----------------+------------+
 | ``p``  | :c:expr:`char[]`         | bytes              |                | \(8)       |
@@ -280,6 +284,9 @@ platform-dependent.
 .. versionchanged:: 3.14
    Added support for the ``'F'`` and ``'D'`` formats.
 
+.. versionchanged:: next
+   Added support for the ``'Zf'`` and ``'Zd'`` formats.
+
 .. seealso::
 
    The :mod:`array` and :ref:`ctypes <ctypes-fundamental-data-types>` modules,
@@ -372,7 +379,7 @@ Notes:
    For the ``'F'`` and ``'D'`` format characters, the packed representation uses
    the IEEE 754 binary32 and binary64 format for components of the complex
    number, regardless of the floating-point format used by the platform.
-   Note that complex types (``F`` and ``D``) are available unconditionally,
+   Note that complex types (``F``/``Zf`` and ``D``/``Zd``) are available unconditionally,
    despite complex types being an optional feature in C.
    As specified in the C11 standard, each complex type is represented by a
    two-element C array containing, respectively, the real and imaginary parts.