Merge remote-tracking branch 'upstream/main' into resume_tracing

Author: Fidget-Spinner

Doc/c-api/float.rst

@@ -201,8 +201,8 @@ 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.
 
-Note that NaNs type may not be preserved on IEEE platforms (signaling NaN become
-quiet NaN), for example on x86 systems in 32-bit mode.
+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.
 
 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
@@ -216,7 +216,7 @@ 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`` ``p+7``), zero if you
+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.

Doc/library/stdtypes.rst

@@ -3514,6 +3514,11 @@ The representation of bytearray objects uses the bytes literal format
 ``bytearray([46, 46, 46])``.  You can always convert a bytearray object into
 a list of integers using ``list(b)``.
 
+.. seealso::
+
+   For detailed information on thread-safety guarantees for :class:`bytearray`
+   objects, see :ref:`thread-safety-bytearray`.
+
 
 .. _bytes-methods:
 

Doc/library/threadsafety.rst

@@ -447,3 +447,104 @@ atomic:
 
 Consider external synchronization when sharing :class:`set` instances
 across threads.  See :ref:`freethreading-python-howto` for more information.
+
+
+.. _thread-safety-bytearray:
+
+Thread safety for bytearray objects
+===================================
+
+   The :func:`len` function is lock-free and :term:`atomic <atomic operation>`.
+
+   Concatenation and comparisons use the buffer protocol, which prevents
+   resizing but does not hold the per-object lock. These operations may
+   observe intermediate states from concurrent modifications:
+
+   .. code-block::
+      :class: maybe
+
+      ba + other    # may observe concurrent writes
+      ba == other   # may observe concurrent writes
+      ba < other    # may observe concurrent writes
+
+   All other operations from here on hold the per-object lock.
+
+   Reading a single element or slice is safe to call from multiple threads:
+
+   .. code-block::
+      :class: good
+
+      ba[i]        # bytearray.__getitem__
+      ba[i:j]      # slice
+
+   The following operations are safe to call from multiple threads and will
+   not corrupt the bytearray:
+
+   .. code-block::
+      :class: good
+
+      ba[i] = x         # write single byte
+      ba[i:j] = values  # write slice
+      ba.append(x)      # append single byte
+      ba.extend(other)  # extend with iterable
+      ba.insert(i, x)   # insert single byte
+      ba.pop()          # remove and return last byte
+      ba.pop(i)         # remove and return byte at index
+      ba.remove(x)      # remove first occurrence
+      ba.reverse()      # reverse in place
+      ba.clear()        # remove all bytes
+
+   Slice assignment locks both objects when *values* is a :class:`bytearray`:
+
+   .. code-block::
+      :class: good
+
+      ba[i:j] = other_bytearray  # both locked
+
+   The following operations return new objects and hold the per-object lock
+   for the duration:
+
+   .. code-block::
+      :class: good
+
+      ba.copy()     # returns a shallow copy
+      ba * n        # repeat into new bytearray
+
+   The membership test holds the lock for its duration:
+
+   .. code-block::
+      :class: good
+
+      x in ba       # bytearray.__contains__
+
+   All other bytearray methods (such as :meth:`~bytearray.find`,
+   :meth:`~bytearray.replace`, :meth:`~bytearray.split`,
+   :meth:`~bytearray.decode`, etc.) hold the per-object lock for their
+   duration.
+
+   Operations that involve multiple accesses, as well as iteration, are never
+   atomic:
+
+   .. code-block::
+      :class: bad
+
+      # NOT atomic: check-then-act
+      if x in ba:
+          ba.remove(x)
+
+      # NOT thread-safe: iteration while modifying
+      for byte in ba:
+          process(byte)  # another thread may modify ba
+
+   To safely iterate over a bytearray that may be modified by another
+   thread, iterate over a copy:
+
+   .. code-block::
+      :class: good
+
+      # Make a copy to iterate safely
+      for byte in ba.copy():
+          process(byte)
+
+   Consider external synchronization when sharing :class:`bytearray` instances
+   across threads.  See :ref:`freethreading-python-howto` for more information.

Doc/whatsnew/3.15.rst

@@ -1014,13 +1014,6 @@ symtable
   (Contributed by Yashp002 in :gh:`143504`.)
 
 
-symtable
---------
-
-* Add :meth:`symtable.Function.get_cells` and :meth:`symtable.Symbol.is_cell` methods.
-  (Contributed by Yashp002 in :gh:`143504`.)
-
-
 sys
 ---
 
@@ -1293,11 +1286,11 @@ Upgraded JIT compiler
 
 Results from the `pyperformance <https://github.com/python/pyperformance>`__
 benchmark suite report
-`4-5% <https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20260110-3.15.0a3%2B-aa8578d-JIT/bm-20260110-vultr-x86_64-python-aa8578dc54df2af9daa3-3.15.0a3%2B-aa8578d-vs-base.svg>`__
+`5-6% <https://doesjitgobrrr.com/run/2026-03-11>`__
 geometric mean performance improvement for the JIT over the standard CPython
 interpreter built with all optimizations enabled on x86-64 Linux. On AArch64
 macOS, the JIT has a
-`7-8% <https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20260110-3.15.0a3%2B-aa8578d-JIT/bm-20260110-macm4pro-arm64-python-aa8578dc54df2af9daa3-3.15.0a3%2B-aa8578d-vs-base.svg>`__
+`8-9% <https://doesjitgobrrr.com/run/2026-03-11>`__
 speedup over the :ref:`tail calling interpreter <whatsnew314-tail-call-interpreter>`
 with all optimizations enabled. The speedups for JIT
 builds versus no JIT builds range from roughly 15% slowdown to over