Brett Cannon [Wed, 19 Nov 2025 23:57:44 +0000 (15:57 -0800)]
Simplify setting CLI options for WASI builds (GH-141769)
This introduces a Wasmtime configuration file to get some CLI options out of the code for easier manipulation. It also allows for easier tweaking after the Makefile is generated.
As well, cut back on the flexibility of specifying HOSTRUNNER for simpler code. The flexibility was never used and so it didn't make sense to keep it around.
Alex Crichton [Wed, 19 Nov 2025 18:03:30 +0000 (12:03 -0600)]
gh-141172: Update to wasi-sdk-29 (GH-141684)
This commit updates CI and configuration from wasi-sdk-25 to wasi-sdk-29
which was released recently. This notably includes stubs for pthreads
which all return errors, so some adjustment in logic is necessary to
retain knowledge that WASI cannot yet spawn threads for example.
This additionally increases the wasm stack allowance to 32MiB from 16MiB
to accomodate the `test_recursive_pickle` test in the
`test_functools.py` file. It looks like the Clang/LLVM update that
happened in wasi-sdk-29 relative to wasi-sdk-25 is likely the cause of
this where presumably functions have more locals than before and/or a
slightly adjusted stack space requirement which overflows the stack.
Miro Hrončok [Wed, 19 Nov 2025 14:02:52 +0000 (15:02 +0100)]
gh-141570: can_colorize: Expect fileno() to raise OSError, as documented (#141716)
In Fedora, we've been given a slightly incomplete reproducer for a problematic
Python 3.14 color-related change in argparse that leads to an exception when
Python is used from mod_wsgi: https://bugzilla.redhat.com/2414940
mod_wsgi replaces sys.stdout with a custom object that raises OSError on .fileno():
Mark Shannon [Wed, 19 Nov 2025 10:16:24 +0000 (10:16 +0000)]
GH-139653: Only raise an exception (or fatal error) when the stack pointer is about to overflow the stack. (GH-141711)
Only raises if the stack pointer is both below the limit *and* above the stack base.
This prevents false positives for user-space threads, as the stack pointer will be outside those bounds
if the stack has been swapped.
The dataclasses `__init__` function is generated dynamically by a call to `exec()` and so doesn't have deferred reference counting enabled. Enable deferred reference counting on functions when assigned as an attribute to type objects to avoid reference count contention when creating dataclass instances.
Victor Stinner [Tue, 18 Nov 2025 16:13:13 +0000 (17:13 +0100)]
gh-141070: Add PyUnstable_Object_Dump() function (#141072)
* Promote _PyObject_Dump() as a public function.
* Keep _PyObject_Dump() alias to PyUnstable_Object_Dump()
for backward compatibility.
* Replace _PyObject_Dump() with PyUnstable_Object_Dump().
Co-authored-by: Peter Bierma <zintensitydev@gmail.com> Co-authored-by: Kumar Aditya <kumaraditya@python.org> Co-authored-by: Petr Viktorin <encukou@gmail.com>
R.C.M [Mon, 17 Nov 2025 14:42:26 +0000 (09:42 -0500)]
gh-130693: Support more options for search in tkinter.Text (GH-130848)
* Add parameters nolinestop and strictlimits in the tkinter.Text.search() method.
* Add the tkinter.Text.search_all() method.
* Add more tests for tkinter.Text.search().
* stopindex is now only ignored if it is None.
Brandt Bucher [Mon, 17 Nov 2025 13:39:00 +0000 (05:39 -0800)]
GH-140643: Add `<native>` and `<GC>` frames to the sampling profiler (#141108)
- Introduce a new field in the GC state to store the frame that initiated garbage collection.
- Update RemoteUnwinder to include options for including "<native>" and "<GC>" frames in the stack trace.
- Modify the sampling profiler to accept parameters for controlling the inclusion of native and GC frames.
- Enhance the stack collector to properly format and append these frames during profiling.
- Add tests to verify the correct behavior of the profiler with respect to native and GC frames, including options to exclude them.
Co-authored-by: Pablo Galindo Salgado <pablogsal@gmail.com>
Serhiy Storchaka [Fri, 14 Nov 2025 14:49:28 +0000 (16:49 +0200)]
gh-122255: Synchronize warnings in C and Python implementations of the warnings module (GH-122824)
In the linecache module and in the Python implementation of the
warnings module, a DeprecationWarning is issued when
m.__loader__ differs from m.__spec__.loader (like in the C
implementation of the warnings module).
Petr Viktorin [Fri, 14 Nov 2025 09:38:49 +0000 (10:38 +0100)]
gh-140550: Use a bool for the Py_mod_gil value (GH-141519)
This needs a single bit, but was stored as a void* in the module
struct. This didn't matter due to packing, but now that there's
another bool in the struct, we can save a bit of memory by
making md_gil a bool.
Variables that changed type are renamed, to detect conflicts.
Ken Jin [Thu, 13 Nov 2025 18:08:32 +0000 (02:08 +0800)]
gh-139109: A new tracing JIT compiler frontend for CPython (GH-140310)
This PR changes the current JIT model from trace projection to trace recording. Benchmarking: better pyperformance (about 1.7% overall) geomean versus current https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251108-3.15.0a1%2B-7e2bc1d-JIT/bm-20251108-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-7e2bc1d-vs-base.svg, 100% faster Richards on the most improved benchmark versus the current JIT. Slowdown of about 10-15% on the worst benchmark versus the current JIT. **Note: the fastest version isn't the one merged, as it relies on fixing bugs in the specializing interpreter, which is left to another PR**. The speedup in the merged version is about 1.1%. https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251112-3.15.0a1%2B-f8a764a-JIT/bm-20251112-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-f8a764a-vs-base.svg
Stats: 50% more uops executed, 30% more traces entered the last time we ran them. It also suggests our trace lengths for a real trace recording JIT are too short, as a lot of trace too long aborts https://github.com/facebookexperimental/free-threading-benchmarking/blob/main/results/bm-20251023-3.15.0a1%2B-eb73378-CLANG%2CJIT/bm-20251023-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-eb73378-pystats-vs-base.md .
This new JIT frontend is already able to record/execute significantly more instructions than the previous JIT frontend. In this PR, we are now able to record through custom dunders, simple object creation, generators, etc. None of these were done by the old JIT frontend. Some custom dunders uops were discovered to be broken as part of this work gh-140277
The optimizer stack space check is disabled, as it's no longer valid to deal with underflow.
Pros:
* Ignoring the generated tracer code as it's automatically created, this is only additional 1k lines of code. The maintenance burden is handled by the DSL and code generator.
* `optimizer.c` is now significantly simpler, as we don't have to do strange things to recover the bytecode from a trace.
* The new JIT frontend is able to handle a lot more control-flow than the old one.
* Tracing is very low overhead. We use the tail calling interpreter/computed goto interpreter to switch between tracing mode and non-tracing mode. I call this mechanism dual dispatch, as we have two dispatch tables dispatching to each other. Specialization is still enabled while tracing.
* Better handling of polymorphism. We leverage the specializing interpreter for this.
Cons:
* (For now) requires tail calling interpreter or computed gotos. This means no Windows JIT for now :(. Not to fret, tail calling is coming soon to Windows though https://github.com/python/cpython/pull/139962
Design:
* After each instruction, the `record_previous_inst` function/label is executed. This does as the name suggests.
* The tracing interpreter lowers bytecode to uops directly so that it can obtain "fresh" values at the point of lowering.
* The tracing version behaves nearly identical to the normal interpreter, in fact it even has specialization! This allows it to run without much of a slowdown when tracing. The actual cost of tracing is only a function call and writes to memory.
* The tracing interpreter uses the specializing interpreter's deopt to naturally form the side exit chains. This allows it to side exit chain effectively, without repeating much code. We force a re-specializing when tracing a deopt.
* The tracing interpreter can even handle goto errors/exceptions, but I chose to disable them for now as it's not tested.
* Because we do not share interpreter dispatch, there is should be no significant slowdown to the original specializing interpreter on tailcall and computed got with JIT disabled. With JIT enabled, there might be a slowdown in the form of the JIT trying to trace.
* Things that could have dynamic instruction pointer effects are guarded on. The guard deopts to a new instruction --- `_DYNAMIC_EXIT`.
Add PyUnstable_ThreadState_SetStackProtection() and
PyUnstable_ThreadState_ResetStackProtection() functions
to set the stack base address and stack size of a Python
thread state.
Cody Maloney [Thu, 13 Nov 2025 13:19:44 +0000 (05:19 -0800)]
gh-139871: Add `bytearray.take_bytes([n])` to efficiently extract `bytes` (GH-140128)
Update `bytearray` to contain a `bytes` and provide a zero-copy path to
"extract" the `bytes`. This allows making several code paths more efficient.
This does not move any codepaths to make use of this new API. The documentation
changes include common code patterns which can be made more efficient with
this API.
---
When just changing `bytearray` to contain `bytes` I ran pyperformance on a
`--with-lto --enable-optimizations --with-static-libpython` build and don't see
any major speedups or slowdowns with this; all seems to be in the noise of
my machine (Generally changes under 5% or benchmarks that don't touch
bytes/bytearray).
Co-authored-by: Victor Stinner <vstinner@python.org> Co-authored-by: Maurycy Pawłowski-Wieroński <5383+maurycy@users.noreply.github.com>
Split existing tests on smaller methods and move them to separate class.
Rename variable "content" to "it".
Use BytesIO instead of StringIO.
Add few more tests.
Serhiy Storchaka [Thu, 13 Nov 2025 11:21:32 +0000 (13:21 +0200)]
gh-135801: Add the module parameter to compile() etc (GH-139652)
Many functions related to compiling or parsing Python code, such as
compile(), ast.parse(), symtable.symtable(),
and importlib.abc.InspectLoader.source_to_code() now allow to pass
the module name used when filtering syntax warnings.
Gregory P. Smith [Thu, 13 Nov 2025 02:15:16 +0000 (18:15 -0800)]
gh-137109: refactor warning about threads when forking (#141438)
* gh-137109: refactor warning about threads when forking
This splits the OS API specific functionality to get the number of threads out
from the fallback Python method and warning raising code itself. This way the
OS APIs can be queried before we've run
`os.register_at_fork(after_in_parent=...)` registered functions which
themselves may (re)start threads that would otherwise be detected.
This is best effort. If the OS APIs are either unavailable or fail, the
warning generating code still falls back to looking at the Python threading
state after the CPython interpreter world has been restarted and the
after_in_parent calls have been made. The common case for most Linux and macOS
environments should work today.
This also lines up with the existing TODO refactoring, we may choose to expose
this API to get the number of OS threads in the `os` module in the future.