Merge branch 'main' into fix-csv-dialect-getattr-exception-masking

Author: picnixz

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/asyncio-task.rst

@@ -557,7 +557,7 @@ Running Tasks Concurrently
       provides stronger safety guarantees than *gather* for scheduling a nesting of subtasks:
       if a task (or a subtask, a task scheduled by a task)
       raises an exception, *TaskGroup* will, while *gather* will not,
-      cancel the remaining scheduled tasks).
+      cancel the remaining scheduled tasks.
 
    .. _asyncio_example_gather:
 

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/tutorial/datastructures.rst

@@ -493,6 +493,9 @@ Curly braces or the :func:`set` function can be used to create sets.  Note: to
 create an empty set you have to use ``set()``, not ``{}``; the latter creates an
 empty dictionary, a data structure that we discuss in the next section.
 
+Because sets are unordered, iterating over them or printing them can
+produce the elements in a different order than you expect.
+
 Here is a brief demonstration::
 
    >>> basket = {'apple', 'orange', 'apple', 'pear', 'orange', 'banana'}

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

Include/internal/pycore_backoff.h

@@ -135,6 +135,20 @@ initial_jump_backoff_counter(_PyOptimizationConfig *opt_config)
         opt_config->jump_backward_initial_backoff);
 }
 
+// This needs to be around 2-4x of JUMP_BACKWARD_INITIAL_VALUE
+// The reasoning is that we always want loop traces to form and inline
+// functions before functions themselves warm up and link to them instead
+// of inlining.
+#define RESUME_INITIAL_VALUE 8190
+#define RESUME_INITIAL_BACKOFF 6
+static inline _Py_BackoffCounter
+initial_resume_backoff_counter(_PyOptimizationConfig *opt_config)
+{
+    return make_backoff_counter(
+        opt_config->resume_initial_value,
+        opt_config->resume_initial_backoff);
+}
+
 /* Initial exit temperature.
  * Must be larger than ADAPTIVE_COOLDOWN_VALUE,
  * otherwise when a side exit warms up we may construct

Include/internal/pycore_code.h

@@ -323,6 +323,7 @@ PyAPI_FUNC(void) _Py_Specialize_ToBool(_PyStackRef value, _Py_CODEUNIT *instr);
 PyAPI_FUNC(void) _Py_Specialize_ContainsOp(_PyStackRef value, _Py_CODEUNIT *instr);
 PyAPI_FUNC(void) _Py_GatherStats_GetIter(_PyStackRef iterable);
 PyAPI_FUNC(void) _Py_Specialize_CallFunctionEx(_PyStackRef func_st, _Py_CODEUNIT *instr);
+PyAPI_FUNC(void) _Py_Specialize_Resume(_Py_CODEUNIT *instr, PyThreadState *tstate, _PyInterpreterFrame *frame);
 
 // Utility functions for reading/writing 32/64-bit values in the inline caches.
 // Great care should be taken to ensure that these functions remain correct and

Include/internal/pycore_interp_structs.h

@@ -14,6 +14,7 @@ extern "C" {
 #include "pycore_structs.h"       // PyHamtObject
 #include "pycore_tstate.h"        // _PyThreadStateImpl
 #include "pycore_typedefs.h"      // _PyRuntimeState
+#include "pycore_uop.h"           // _PyBloomFilter
 
 #define CODE_MAX_WATCHERS 8
 #define CONTEXT_MAX_WATCHERS 8
@@ -413,6 +414,9 @@ typedef struct _PyOptimizationConfig {
     uint16_t jump_backward_initial_value;
     uint16_t jump_backward_initial_backoff;
 
+    uint16_t resume_initial_value;
+    uint16_t resume_initial_backoff;
+
     // JIT optimization thresholds
     uint16_t side_exit_initial_value;
     uint16_t side_exit_initial_backoff;
@@ -972,7 +976,10 @@ struct _is {
 
     // Optimization configuration (thresholds and flags for JIT and interpreter)
     _PyOptimizationConfig opt_config;
-    struct _PyExecutorObject *executor_list_head;
+    _PyBloomFilter *executor_blooms;             // Contiguous bloom filter array
+    struct _PyExecutorObject **executor_ptrs;    // Corresponding executor pointer array
+    size_t executor_count;                       // Number of valid executors
+    size_t executor_capacity;                    // Array capacity
     struct _PyExecutorObject *executor_deletion_list_head;
     struct _PyExecutorObject *cold_executor;
     struct _PyExecutorObject *cold_dynamic_executor;

Include/internal/pycore_magic_number.h

@@ -292,6 +292,7 @@ Known values:
     Python 3.15a4 3659 (Add CALL_FUNCTION_EX specialization)
     Python 3.15a4 3660 (Change generator preamble code)
     Python 3.15a4 3661 (Lazy imports IMPORT_NAME opcode changes)
+    Python 3.15a6 3662 (Add counter to RESUME)
 
 
     Python 3.16 will start with 3700
@@ -305,7 +306,7 @@ PC/launcher.c must also be updated.
 
 */
 
-#define PYC_MAGIC_NUMBER 3661
+#define PYC_MAGIC_NUMBER 3662
 /* This is equivalent to converting PYC_MAGIC_NUMBER to 2 bytes
    (little-endian) and then appending b'\r\n'. */
 #define PYC_MAGIC_NUMBER_TOKEN \