To choose the node version we use. Together with:
https://github.com/python/buildmaster-config/pull/614
closes GH-136852.
(cherry picked from commit aec7f5f8b2e8b5e02869cdb4e1f8a9ef87c9f953)
[3.14] gh-134411: assert `PyLong_FromLong(x) != NULL` when `x` is known to be small (GH-134415) (#136910)
gh-134411: assert `PyLong_FromLong(x) != NULL` when `x` is known to be small (GH-134415)
Since `PyLong_From Long(PY_MONITORING_DEBUGGER_ID)` falls to `small_int` case and can't return `NULL`. Added `assert`s for extra confidence.
https://github.com/python/cpython/issues/134411#issuecomment-2897653868
(cherry picked from commit cf19b6435d02dd7be11b84a44f4a8a9f1a935b15)
UUIDv8 has been added in Python 3.14.0a2 and its construction time
has been improved in Python 3.14.0a4, but since those changes will
not be visible when comparing the latest Python 3.13 and 3.14 together,
we do not document them on the What's New page to avoid confusion.
(cherry picked from commit 5798348a0739ccf46f690f5fa1443080ec5de310)
[3.14] gh-136470: Correct InterpreterPoolExecutor's default thread name (GH-136472) (GH-136889)
gh-136470: Correct InterpreterPoolExecutor's default thread name (GH-136472)
The OS thread name is now correctly prefixed with `InterpreterPoolExecutor` instead of `ThreadPoolExecutor`.
(cherry picked from commit 246be21de1e2a51d757c747902108dfec13e0605)
Co-authored-by: AN Long <aisk@users.noreply.github.com>
Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com> Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com> Co-authored-by: Łukasz Langa <lukasz@langa.pl> Co-authored-by: Adam Turner <9087854+aa-turner@users.noreply.github.com>
[3.14] Doc/c-api/memory.rst: extend --without-pymalloc doc with ASan information (GH-136790) (GH-136798)
Extend the documentation for disabling pymalloc with the `--without-pymalloc` flag regarding why it is worth to use it when enabling AddressSanitizer for Python build (which is done, e.g., in CPython's CI builds).
I have tested the CPython latest main build with both ASan and pymalloc enabled and it seems to work just fine. I did run the `python -m test` suite which didn't uncover any ASan crashes (though, it detected some memory leaks, which I believe are irrelevant here).
I have discussed ASan and this flag with @encukou on the CPython Core sprint on EuroPython 2025. We initially thought that the `--without-pymalloc` flag is needed for ASan builds due to the fact pymalloc must hit the begining of page when determining if the memory to be freed comes from pymalloc or was allocated by the system malloc. In other words, we thought, that ASan would crash CPython during free of big objects (allocated by system malloc). It may be that this was the case in the past, but it is not the case anymore as the `address_in_range` function used by pymalloc is annotated to be skipped from the ASan instrumentation.
[3.14] gh-136769: Include fixed-width integers in the fundamental data types table (GH-136784) (#136785)
gh-136769: Include fixed-width integers in the fundamental data types table (GH-136784)
Fixed-sized types, like ``c_int32``, are currently missing from the fundamental data types table
in the ``ctypes`` documentation. This commit adds them, and notes that ``c_[u]int8`` is an alias
of ``c_[u]byte``.
(cherry picked from commit acefb978dcb5dd554e3c49a3015ee5c2ad6bfda1)
Co-authored-by: Sina Zel taat <111974143+SZeltaat@users.noreply.github.com>
[3.14] Docs: Improve example for ``itertools.batched()`` (GH-136775) (#136778)
Docs: Improve example for ``itertools.batched()`` (GH-136775)
The current example `batched('ABCDEFG', n=3) → ABC DEF G` can confuse readers because both, the size of the tuples and the number of tuples are 3.
By using a batch size of n=2, it is clearer that the `n` argument refers to the size of the resulting tuples.
I.e. the new example is: `batched('ABCDEFG', n=2) → AB CD EF G`
(cherry picked from commit 3eecc72ac70943f7e33297eea17803af15322c88)
[3.14] gh-127146: Emscripten: Set umask to zero in python.sh (GH-136740) (#136745)
Clears the umask used during a test of pydoc.apropos when testing on
Emscripten. This is to work around a known issue in Emscripten; but it's not
clear if the chmod call that is causing the problem is actually testing
anything of significance.
(cherry picked from commit 22af5d35a620ee44393853036a8450ceb047688e)
[3.14] gh-127146: Emscripten: Don't need to avoid unpaired surrogate anymore (GH-136707) (#136717)
This might have been fixed by gh-136624, or by some Emscripten change.
In any case, it no longer seems to be needed.
(cherry picked from commit dcd27aace180737adaddc79c00c181816fc6e162)
[3.14] gh-127146: Emscripten: Make os.umask() actually work (GH-136706) (#136711)
Provide a stub implementation of umask that is enough to get some tests passing.
More work is needed upstream in Emscripten to make all umask tests to pass.
(cherry picked from commit 12e52cad718723636a96042f9399634392285c44)
[3.14] gh-127146: Emscripten: more regular stack overflow skips (GH-136708) (#136712)
Makes the Emscripten stack overflow skip message consistent with WASI,
and replaces some ad-hoc skips.
(cherry picked from commit c730952aa64b790c75c437cb63a1242dc08c2e97)
[3.14] gh-136396: Include instrumentation when creating new copies of the bytecode (GH-136525) (GH-136657)
Previously, we assumed that instrumentation would happen for all copies of
the bytecode if the instrumentation version on the code object didn't match
the per-interpreter instrumentation version. That assumption was incorrect:
instrumentation will exit early if there are no new "events," even if there
is an instrumentation version mismatch.
To fix this, include the instrumented opcodes when creating new copies of
the bytecode, rather than replacing them with their uninstrumented variants.
I don't think we have to worry about races between instrumentation and creating
new copies of the bytecode: instrumentation and new bytecode creation cannot happen
concurrently. Instrumentation requires that either the world is stopped or the
code object's per-object lock is held and new bytecode creation requires holding
the code object's per-object lock.
(cherry picked from commit d995922198304a6de19ac1bec3e36d1e886d8468)
[3.14] gh-131189: Fix "msvcrt" import warning on Linux when "_ctypes" is not available. (GH-131201) (GH-136668)
Fix "msvcrt" import warning on Linux when "_ctypes" is not available.
On Linux, compiling without "libffi" causes a
"No module named 'msvcrt'" warning when launching PyREPL.
(cherry picked from commit f320c951c3220aa6727b581216463e8b3f8bcd6b)
[3.14] gh-116738: Make grp module thread-safe (GH-135434) (#136658)
gh-116738: Make grp module thread-safe (GH-135434)
Make grp module methods getgrgid() and getgrnam() thread-safe when the GIL is disabled and getgrgid_r()/getgrnam_r() C APIs are not available.
---------
(cherry picked from commit 9363703bd3bf86e363c14a02e3d729caf1e29f44)
[3.14] gh-127146: Emscripten: Fix test_open_undecodable_uri by setting `-sTEXTDECODER=2` (GH-136624) (#136631)
Removes the JS text decoder fallback and gets rid of the bugs due to the differences
in behavior on invalid utf8 strings. See https://github.com/emscripten-core/emscripten/issues/24690.
(cherry picked from commit 283b05052338dd735cd4927011afc3735d9c6c7c)
[3.14] Docs: Fix and improve the `PyUnstable_Object_EnableDeferredRefcount` documentation (GH-135323) (GH-136610)
Docs: Fix and improve the `PyUnstable_Object_EnableDeferredRefcount` documentation (GH-135323)
(cherry picked from commit 0d4fd10fbab2767fad3eb27639905c8885b88c89)
Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
[3.14] gh-91153: prevent a crash in `bytearray.__setitem__(ind, ...)` when `ind.__index__` has side-effects (GH-132379) (#136581)
gh-91153: prevent a crash in `bytearray.__setitem__(ind, ...)` when `ind.__index__` has side-effects (GH-132379)
(cherry picked from commit 5e1e21dee35b8e9066692d08033bbbdb562e2c28)
[3.14] gh-136541: Fix several problems of perf trampolines in x86_64 and aarch64 (GH-136500) (#136544)
gh-136541: Fix several problems of perf trampolines in x86_64 and aarch64 (GH-136500)
This commit fixes the following problems:
* The x86_64 trampolines are not preserving frame pointers
* The hardcoded offsets to the code segment from the FDE only worked properly for x64_64
* The CIE data was not following conventions of aarch64
* The eh_frame for aarch64 was not fully correct
(cherry picked from commit 236f733d8ffb3d587e1167fa0a0248c24512e7fd)
Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
Co-authored-by: Zachary Ware <zach@python.org> Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com> Co-authored-by: Éric <merwok@netwok.org>
[3.14] GH-133136: Revise QSBR to reduce excess memory held (gh-135473) (#135912)
The free threading build uses QSBR to delay the freeing of dictionary
keys and list arrays when the objects are accessed by multiple threads
in order to allow concurrent reads to proceed with holding the object
lock. The requests are processed in batches to reduce execution
overhead, but for large memory blocks this can lead to excess memory
usage.
Take into account the size of the memory block when deciding when to
process QSBR requests.
Also track the amount of memory being held by QSBR for mimalloc pages. Advance the write sequence if this memory exceeds a limit. Advancing the sequence will allow it to be freed more quickly.
Process the held QSBR items from the "eval breaker", rather than from `_PyMem_FreeDelayed()`. This gives a higher chance that the global read sequence has advanced enough so that items can be freed.
[3.14] gh-136380: Fix import behavior for `concurrent.futures.InterpreterPoolExecutor` (GH-136381) (#136420)
gh-136380: Fix import behavior for `concurrent.futures.InterpreterPoolExecutor` (GH-136381)
(cherry picked from commit 490eea02819ad303a5042529af7507b7b1fdabdc)
Co-authored-by: AN Long <aisk@users.noreply.github.com> Co-authored-by: Serhiy Storchaka <storchaka@gmail.com> Co-authored-by: Peter Bierma <zintensitydev@gmail.com> Co-authored-by: sobolevn <mail@sobolevn.me>
projects / thirdparty / Python / cpython.git / log
