gh-134411: assert `PyLong_FromLong(x) != NULL` when `x` is known to be small (#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
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.
GH-130645: Default to color help in argparse (#136809)
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>
gh-134531: prefer using `_hashlib` module state instead of module object (#136865)
Some internal helper functions taking the module object to retrieve its state
under some conditions now directly take the module's state instead as those
conditions hold most of the time.
gh-136547: fix `hashlib_helper` for blocking and requesting digests (#136762)
- Fix `hashlib_helper.block_algorithm` where the dummy functions were incorrectly defined.
- Rename `hashlib_helper.HashAPI` to `hashlib_helper.HashInfo` and add more helper methods.
- Simplify `hashlib_helper.requires_*()` functions.
- Rewrite some private helpers in `hashlib_helper`.
- Remove `find_{builtin,openssl}_hashdigest_constructor()` as they are no more needed and were
not meant to be public in the first place.
- Fix some tests in `test_hashlib` when FIPS mode is on.
gh-124621: Emscripten: Add support for async input devices (GH-136822)
This is useful for implementing proper `input()`. It requires the
JavaScript engine to support the wasm JSPI spec which is now stage 4.
It is supported on Chrome since version 137 and on Firefox and node
behind a flag.
We override the `__wasi_fd_read()` syscall with our own variant that
checks for a readAsync operation. If it has it, we use our own async
variant of `fd_read()`, otherwise we use the original `fd_read()`.
We also add a variant of `FS.createDevice()` called
`FS.createAsyncInputDevice()`.
Finally, if JSPI is available, we wrap the `main()` symbol with
`WebAssembly.promising()` so that we can stack switch from `fd_read()`.
If JSPI is not available, attempting to read from an AsyncInputDevice
will raise an `OSError`.
Doc/c-api/memory.rst: extend --without-pymalloc doc with ASan information (GH-136790)
* Doc/c-api/memory.rst: extend --without-pymalloc doc with ASan information
This commit extends 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.
And the corresponding attribute is documented in:
* for gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-no_005fsanitize_005faddress-function-attribute
* for clang: https://clang.llvm.org/docs/AttributeReference.html#no-sanitize-address-no-address-safety-analysis
* Update Doc/c-api/memory.rst
* Improve --with-address-sanitizer and pymalloc docs
gh-136769: Include fixed-width integers in the fundamental data types table (#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``.
Docs: Improve example for ``itertools.batched()`` (#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`
gh-136438: Make sure `test_ast` pass with all optimization levels (#136596)
Explicitly pass an `optimizer` parameter to the calls of `ast.parse/compile`, because if it is not provided, the interpreter will use its internal state, which can be modified using the `-O` or `-OO` flags.
Make the pwd module functions getpwuid(), getpwnam(), and getpwall() thread-safe. These changes apply to scenarios where the GIL is disabled or in subinterpreter use cases.
gh-127146: Emscripten: Set umask to zero in python.sh (#136740)
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.
gh-127146: Emscripten: Make os.umask() actually work (#136706)
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.
gh-135909: Assert incoming `refcnt != 0` for the free threaded GC (GH-136009)
This helps catch double deallocation bugs and is similar to the
assertion in the GIL-enabled build. The call to `validate_refcounts`
is moved up to start of the GC because `queue_untracked_obj_decref()`
creates it own zero reference count garbage.
Richard Si [Tue, 15 Jul 2025 14:25:07 +0000 (10:25 -0400)]
gh-72327: Suggest using system terminal for pip install in PyREPL (#136328)
Users new to Python packaging often try to use pip from the REPL only to
be met with a confusing SyntaxError. If this happens, guide the user to
use a system terminal instead to invoke pip.
Closes #72327
---------
Co-authored-by: Tom Viner <tom@viner.tv> Co-authored-by: Brian Schubert <brianm.schubert@gmail.com> Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com> Co-authored-by: Alyssa Coghlan <ncoghlan@gmail.com>
Make grp module methods getgrgid() and getgrnam() thread-safe when the GIL is disabled and getgrgid_r()/getgrnam_r() C APIs are not available.
---------
gh-136396: Include instrumentation when creating new copies of the bytecode (#136525)
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.
gh-127146: Emscripten: Fix test_open_undecodable_uri by setting `-sTEXTDECODER=2` (#136624)
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.
gh-121914: Change the names of the symbol tables for lambda and genexpr (GH-135288)
Change the names of the symbol tables for lambda expressions and generator
expressions to "<lambda>" and "<genexpr>" respectively to avoid conflicts
with user-defined names.
gh-132629: Deprecate accepting out-of-range values for unsigned integers in PyArg_Parse (GH-132630)
For unsigned integer formats in the PyArg_Parse* functions,
accepting Python integers with value that is larger than
the maximal value the corresponding C type or less than
the minimal value for the corresponding signed integer type
is now deprecated.