Merge branch 'main' into emscripten-run-test

Author: freakboy3742

Doc/c-api/buffer.rst

@@ -500,10 +500,11 @@ Buffer-related functions
    *indices* must point to an array of ``view->ndim`` indices.
 
 
-.. c:function:: int PyBuffer_FromContiguous(const Py_buffer *view, const void *buf, Py_ssize_t len, char fort)
+.. c:function:: int PyBuffer_FromContiguous(const Py_buffer *view, const void *buf, Py_ssize_t len, char order)
 
    Copy contiguous *len* bytes from *buf* to *view*.
-   *fort* can be ``'C'`` or ``'F'`` (for C-style or Fortran-style ordering).
+   *order* can be ``'C'`` or ``'F'`` or ``'A'`` (for C-style or Fortran-style
+   ordering or either one).
    ``0`` is returned on success, ``-1`` on error.
 
 

Doc/c-api/float.rst

@@ -190,24 +190,23 @@ The pack and unpack functions provide an efficient platform-independent way to
 store floating-point values as byte strings. The Pack routines produce a bytes
 string from a C :c:expr:`double`, and the Unpack routines produce a C
 :c:expr:`double` from such a bytes string. The suffix (2, 4 or 8) specifies the
-number of bytes in the bytes string.
+number of bytes in the bytes string:
 
-On platforms that appear to use IEEE 754 formats these functions work by
-copying bits. On other platforms, the 2-byte format is identical to the IEEE
-754 binary16 half-precision format, the 4-byte format (32-bit) is identical to
-the IEEE 754 binary32 single precision format, and the 8-byte format to the
-IEEE 754 binary64 double precision format, although the packing of INFs and
-NaNs (if such things exist on the platform) isn't handled correctly, and
-attempting to unpack a bytes string containing an IEEE INF or NaN will raise an
-exception.
+* The 2-byte format is the IEEE 754 binary16 half-precision format.
+* The 4-byte format is the IEEE 754 binary32 single-precision format.
+* The 8-byte format is the IEEE 754 binary64 double-precision format.
 
-Note that NaN type may not be preserved on IEEE platforms (signaling NaNs become
-quiet NaNs), for example on x86 systems in 32-bit mode.
+The NaN type may not be preserved on some platforms while unpacking (signaling
+NaNs become quiet NaNs), for example on x86 systems in 32-bit mode.
 
+It's assumed that the :c:expr:`double` type has the IEEE 754 binary64 double
+precision format.  What happens if it's not true is partly accidental (alas).
 On non-IEEE platforms with more precision, or larger dynamic range, than IEEE
 754 supports, not all values can be packed; on non-IEEE platforms with less
-precision, or smaller dynamic range, not all values can be unpacked. What
-happens in such cases is partly accidental (alas).
+precision, or smaller dynamic range, not all values can be unpacked.  The
+packing of special numbers like INFs and NaNs (if such things exist on the
+platform) may not be handled correctly, and attempting to unpack a bytes string
+containing an IEEE INF or NaN may raise an exception.
 
 .. versionadded:: 3.11
 
@@ -217,9 +216,9 @@ Pack functions
 The pack routines write 2, 4 or 8 bytes, starting at *p*. *le* is an
 :c:expr:`int` argument, non-zero if you want the bytes string in little-endian
 format (exponent last, at ``p+1``, ``p+3``, or ``p+6`` and ``p+7``), zero if you
-want big-endian format (exponent first, at *p*). The :c:macro:`PY_BIG_ENDIAN`
-constant can be used to use the native endian: it is equal to ``1`` on big
-endian processor, or ``0`` on little endian processor.
+want big-endian format (exponent first, at *p*). Use the :c:macro:`!PY_LITTLE_ENDIAN`
+constant to select the native endian: it is equal to ``0`` on big
+endian processor, or ``1`` on little endian processor.
 
 Return value: ``0`` if all is OK, ``-1`` if error (and an exception is set,
 most likely :exc:`OverflowError`).
@@ -236,21 +235,27 @@ most likely :exc:`OverflowError`).
 
    Pack a C double as the IEEE 754 binary64 double precision format.
 
+   .. impl-detail::
+      This function always succeeds in CPython.
+
 
 Unpack functions
 ^^^^^^^^^^^^^^^^
 
 The unpack routines read 2, 4 or 8 bytes, starting at *p*.  *le* is an
 :c:expr:`int` argument, non-zero if the bytes string is in little-endian format
 (exponent last, at ``p+1``, ``p+3`` or ``p+6`` and ``p+7``), zero if big-endian
-(exponent first, at *p*). The :c:macro:`PY_BIG_ENDIAN` constant can be used to
-use the native endian: it is equal to ``1`` on big endian processor, or ``0``
+(exponent first, at *p*). Use the :c:macro:`!PY_LITTLE_ENDIAN` constant to
+select the native endian: it is equal to ``0`` on big endian processor, or ``1``
 on little endian processor.
 
 Return value: The unpacked double.  On error, this is ``-1.0`` and
 :c:func:`PyErr_Occurred` is true (and an exception is set, most likely
 :exc:`OverflowError`).
 
+.. impl-detail::
+    These functions always succeed in CPython.
+
 .. c:function:: double PyFloat_Unpack2(const char *p, int le)
 
    Unpack the IEEE 754 binary16 half-precision format as a C double.

Doc/tools/.nitignore

@@ -3,7 +3,6 @@
 # Keep lines sorted lexicographically to help avoid merge conflicts.
 
 Doc/c-api/descriptor.rst
-Doc/c-api/float.rst
 Doc/c-api/init_config.rst
 Doc/c-api/intro.rst
 Doc/c-api/stable.rst

Doc/tools/extensions/c_annotations.py

@@ -308,27 +308,27 @@ def _unstable_api_annotation() -> nodes.admonition:
 def _threadsafety_annotation(level: str) -> nodes.emphasis:
     match level:
         case "incompatible":
-            display = sphinx_gettext("Not safe to call from multiple threads.")
+            display = sphinx_gettext("Not safe to call from multiple threads")
             reftarget = "threadsafety-level-incompatible"
         case "compatible":
             display = sphinx_gettext(
                 "Safe to call from multiple threads"
-                " with external synchronization only."
+                " with external synchronization only"
             )
             reftarget = "threadsafety-level-compatible"
         case "distinct":
             display = sphinx_gettext(
                 "Safe to call without external synchronization"
-                " on distinct objects."
+                " on distinct objects"
             )
             reftarget = "threadsafety-level-distinct"
         case "shared":
             display = sphinx_gettext(
-                "Safe for concurrent use on the same object."
+                "Safe for concurrent use on the same object"
             )
             reftarget = "threadsafety-level-shared"
         case "atomic":
-            display = sphinx_gettext("Atomic.")
+            display = sphinx_gettext("Atomic")
             reftarget = "threadsafety-level-atomic"
         case _:
             raise AssertionError(f"Unknown thread safety level {level!r}")
@@ -340,9 +340,11 @@ def _threadsafety_annotation(level: str) -> nodes.emphasis:
         reftype="ref",
         refexplicit="True",
     )
-    prefix = sphinx_gettext("Thread safety:") + " "
+    prefix = " " + sphinx_gettext("Thread safety:") + " "
     classes = ["threadsafety", f"threadsafety-{level}"]
-    return nodes.emphasis("", prefix, ref_node, classes=classes)
+    return nodes.emphasis(
+        "", prefix, ref_node, nodes.Text("."), classes=classes
+    )
 
 
 def _return_value_annotation(result_refs: int | None) -> nodes.emphasis:

Doc/whatsnew/3.15.rst

@@ -1358,7 +1358,7 @@ The JIT avoids :term:`reference count`\ s where possible. This generally
 reduces the cost of most operations in Python.
 
 (Contributed by Ken Jin, Donghee Na, Zheao Li, Hai Zhu, Savannah Ostrowski,
-Reiden Ong, Noam Cohen, Tomas Roun, PuQing, and Cajetan Rodrigues in :gh:`134584`.)
+Reiden Ong, Noam Cohen, Tomas Roun, PuQing, Cajetan Rodrigues, and Sacul in :gh:`134584`.)
 
 .. rubric:: Better machine code generation