Most importantly, this resolves the issues with functions and types defined in __main__.
It also expands the number of supported objects and simplifies the implementation.
* Remove duplicated code. Tests for Random and SystemRandom now share
the code.
* Move implementation agnostic tests that was only run for SystemRandom,
so they are now run for Random too.
* Add tests for __index__() support.
* Add tests for randint().
If a preloaded module writes to stdout or stderr, and the stream is buffered,
child processes will inherit the buffered data after forking. Attempt to
prevent this by flushing the streams after preload.
Co-authored-by: Mikhail Efimov <efimov.mikhail@gmail.com>
Co-authored-by: Victor Stinner <vstinner@python.org>
The Emscripten path resolver uses the same mechanism for resolving `..`
at a file system root as for resolving symlinks. This is because
roots don't store their mountpoints. If the parent of a node is itself,
it is a root but it might be a mountpoint in some other file system.
If a path has enough `..`'s at the root, it will return ELOOP.
Enough turns out to be 49.
As noted in the new tests, there are a few situations we must carefully accommodate
for functions that get pickled during interp.call(). We do so by running the script
from the main interpreter's __main__ module in a hidden module in the other
interpreter. That hidden module is used as the function __globals__.
This PR adds a PyJitRef API to the JIT's optimizer that mimics the _PyStackRef API. This allows it to track references and their stack lifetimes properly. Thus opening up the doorway to refcount elimination in the JIT.
* gh-134632: Fix `build-details.json` to use `INCLUDEPY` path
Fix ``build-details.json`` generation to use ``INCLUDEPY``, in order to
reference the ``pythonX.Y`` subdirectory of the include directory, as
required in :pep:`739`, instead of the top-level include directory.
* test_build_details: Add tests for the c_api section
* test_build_details: Expect pkgconfig for CPython unconditionally
For several builtin functions, we now fall back to __main__.__dict__ for the globals
when there is no current frame and _PyInterpreterState_IsRunningMain() returns
true. This allows those functions to be run with Interpreter.call().
The affected builtins:
* exec()
* eval()
* globals()
* locals()
* vars()
* dir()
We take a similar approach with "stateless" functions, which don't use any
global variables.
Use `ma_used` instead of `ma_keys->dk_nentries` for modification check
so that we only check if the dictionary is modified, not if new keys are
added to a different dictionary that shared the same keys object.
* gh-67022: Document bytes/str inconsistency in email.header.decode_header()
This function's possible return types have been surprising and error-prone
for the entirety of its Python 3.x history. It can return either:
1. `typing.List[typing.Tuple[bytes, typing.Optional[str]]]` of length >1
2. or `typing.List[typing.Tuple[str, None]]`, of length exactly 1
This means that any user of this function must be prepared to accept either
`bytes` or `str` for the first member of the 2-tuples it returns, which is a
very surprising behavior in Python 3.x, particularly given that the second
member of the tuple is supposed to represent the charset/encoding of the
first member.
This patch documents the behavior of this function, and adds test cases
to demonstrate it.
As discussed in bpo-22833, this cannot be changed in a backwards-compatible
way, and some users of this function depend precisely on the existing
behavior.
Add warnings about obsolescence of 'email.header.decode_header' and 'email.header.make_header' functions.
Recommend use of `email.headerregistry.HeaderRegistry` instead, as suggested
in https://github.com/python/cpython/pull/92900#discussion_r1112472177
Prior to issue #120485 these servers did not allow port reuse, which
makes sense as the behavior of port reuse is surprising if you're not
expecting it. It's unclear to me why these services were switched to
allow port reuse, but I believe the desired behavior (unless subclasses
opt in) is to not allow port reuse.
See also: https://bugzilla.redhat.com/show_bug.cgi?id=2323170
PEP-734 has been accepted (for 3.14).
(FTR, I'm opposed to putting this under the concurrent package, but
doing so is the SC condition under which the module can land in 3.14.)
When shutdown is called with wait=False, the executor thread keeps running
even after the ProcessPoolExecutor's state is reset. The executor then tries
to replenish the worker processes pool resulting in an error and a potential hang
when it comes across a worker that has died. Fixed the issue by having
_adjust_process_count() return without doing anything if the ProcessPoolExecutor's
state has been reset.
Added unit tests to validate two scenarios:
max_workers < num_tasks (exception)
max_workers > num_tasks (exception + hang)
Use critical sections to make heapq methods that update the heap thread-safe when the GIL is disabled.
---------
Co-authored-by: mpage <mpage@meta.com>
