Files
RustPython/Lib
Jeong, YunWon 259ce8ce66 Fix the itertools.tee leak and race, the contextvars and generator races, _asyncio's InvalidStateError lookup, and _imp's frozen data (#8518)
* _imp: read get_frozen_object's data as a whole marshal value

The data argument went through deserialize_code(), which reads a code body
without the type byte in front of it, so nothing marshal.dumps() produces was
accepted. Read it with marshal.loads() and require a code object back.

Assisted-by: Claude

* _imp: bind find_frozen's arguments with FromArgs

The arity check was done by hand on a FuncArgs. Take the arguments through a
FromArgs struct instead, which makes withdata keyword-only, and fill in the
data it asks for: the frozen encoding is not marshal, so the code is
re-serialized into what get_frozen_object() reads back.

Assisted-by: Claude

* itertools: give tee's shared buffer a Python type

The buffer was a PyRc<PyItertoolsTeeData>, which is not a Python object, so the
collector could not walk into it and any cycle running through a tee was
uncollectable. Make it the _tee_dataobject type with a traverse, held by
PyRef, and split the rest along the same lines: tee() is a function, _tee is
the iterator type it builds, and _tee takes a single iterable rather than
returning a tuple from __new__. _tee is weak-referenceable, tee() rejects a
negative n with ValueError and reserves its tuple fallibly.

test_itertools.test_tee passes now; its expectedFailure marker is removed.

Assisted-by: Claude

* contextvars: hold the shared context state under locks

The variable map was a RefCell, the enter flag, the context index, the token's
used flag and the variable hash were Cells, and each carried an unsafe impl
Sync. A Context or ContextVar shared between threads overlapped their borrows
and panicked. The map and the per-variable cache are now PyMutex, the flags and
the index are atomics, entering a context is a compare_exchange, and the three
unsafe impl Sync are gone.

The cache also stopped being read through AtomicCell::as_ptr, which raced a
concurrent store on a value holding a PyObjectRef.

Values displaced from the map or the cache are dropped after the lock is
released: __del__ can come straight back into the same context, and the locks
are not reentrant.

Assisted-by: Claude

* generator: read the frame state under the running claim

send(), send_none(), throw() and close() read `closed` and `frame.lasti()`
before `running` was compare_exchanged, so the frame they went on to resume
could be one another thread had already advanced. A resume that decided from
`lasti() == 0` that the generator had not started pushes no value onto the
value stack, and the code after the yield pops one, which underflows the stack.

The compare_exchange now hands back a guard, taken before those reads and
released after maybe_close(), so the generator is retired while it is still
claimed.

Assisted-by: Claude

* itertools: claim a tee's position and its buffer as one step

`_tee::next` read `index` and moved it on afterwards, and
`_tee_dataobject::get_item` released `running` before the value it fetched
from the source was cached.

Two callers on one `_tee` then read the same index, hand out the same value
twice and advance past a value that was never cached, which leaves `index`
past `values.len()` and indexes the buffer out of bounds. Two callers at the
same index on separate tees each fetch a value from the source, and one of the
two is dropped without reaching a caller.

Both claims now cover the read and the update.

Assisted-by: Claude

* _asyncio: require InvalidStateError to be a type

new_invalid_state_error() called whatever `asyncio.exceptions.InvalidStateError`
names and unwrapped the downcast of the result, so a future asked for a result
it does not have panicked once that attribute was rebound to something that is
not an exception:

    asyncio.InvalidStateError = lambda *args: 42
    _asyncio.Future(loop=object()).result()

The type is looked up the way get_cancelled_error_type() looks its own up, and
raised with new_exception_msg; a lookup that does not produce an exception type
falls back to RuntimeError, as the other arms already did.

Assisted-by: Claude
2026-08-14 16:05:30 +09:00
..
2026-06-12 11:10:50 +09:00
2026-05-17 20:54:56 +09:00
2026-06-15 11:21:28 +09:00
2026-05-12 00:42:54 +09:00
2026-01-20 15:29:05 +09:00
2026-01-17 19:21:11 +09:00
2026-05-12 20:52:36 +09:00
2026-06-15 11:20:13 +09:00
2026-06-15 11:19:40 +09:00
2026-06-15 11:19:40 +09:00
2026-05-20 23:09:50 +09:00
2025-03-20 14:28:26 +09:00
2025-03-10 11:43:53 +09:00
2026-02-02 01:20:23 +09:00
2025-01-11 18:48:27 +09:00
2025-03-10 11:43:53 +09:00
2025-03-10 23:13:32 -07:00
2026-02-13 13:55:05 +09:00
2026-02-24 01:07:30 +00:00
2026-01-30 19:21:10 +09:00
2026-02-02 01:20:23 +09:00
2026-02-28 12:09:59 +09:00
2026-01-31 10:11:58 +09:00
2025-04-21 20:45:06 -07:00
2026-01-24 00:24:12 +09:00
2026-02-18 00:43:49 +09:00
2026-02-24 01:07:30 +00:00
2026-01-30 16:38:36 +02:00
2026-02-08 20:36:35 +09:00
2026-01-26 10:40:22 +09:00
2026-02-11 16:47:03 +09:00
2025-04-30 14:33:52 +09:00
2026-01-30 07:48:29 +09:00
2026-02-08 16:35:56 +09:00
2026-02-08 16:35:56 +09:00
2026-02-14 21:40:04 +09:00
2026-02-15 21:04:32 +09:00
2026-05-12 20:53:24 +09:00
2026-02-13 14:13:30 +09:00
2026-02-09 12:56:53 +09:00
2026-02-14 18:19:57 +02:00
2026-01-21 20:14:30 +09:00
2026-01-25 00:18:55 +09:00
2026-03-01 14:51:54 +09:00
2026-01-23 23:57:31 +09:00
2026-06-11 13:36:30 +09:00
2026-05-17 19:49:42 +09:00
2026-03-03 20:00:50 +09:00
2026-03-12 18:08:56 +09:00
2026-02-13 20:24:57 +09:00
2026-02-06 01:14:55 +09:00
2026-05-12 20:51:02 +09:00
2025-07-25 10:50:17 +09:00
2026-02-13 18:07:25 +09:00
2026-02-04 18:32:45 +09:00
2026-05-17 19:49:09 +09:00
…
2026-01-21 15:10:40 +09:00
2026-05-12 20:51:46 +09:00
2025-04-21 21:11:42 -07:00
2025-07-17 00:04:12 +09:00
2024-04-26 01:39:02 +09:00
2026-05-12 00:43:34 +09:00
2026-05-12 20:51:57 +09:00
2026-05-13 19:52:56 +09:00
2024-03-22 14:54:02 +09:00
2024-03-22 14:54:02 +09:00
2026-03-01 11:36:46 +09:00
2026-02-14 09:18:09 +09:00
2026-02-11 18:01:41 +09:00
2026-01-21 03:05:05 +09:00
2026-01-30 19:13:59 +02:00
…
2026-05-12 20:53:11 +09:00
2026-01-22 08:02:43 +09:00
2026-03-10 11:28:16 +09:00
2026-03-04 05:38:58 +09:00
2026-06-03 18:36:37 +09:00
2026-06-15 11:20:13 +09:00
2026-06-15 11:20:13 +09:00
2026-06-02 18:00:54 +09:00
2026-02-13 13:42:22 +09:00
2026-01-30 19:21:10 +09:00
2026-03-05 17:25:59 +09:00

Standard Library for RustPython

This directory contains all of the Python files that make up the standard library for RustPython.

Most of these files are copied over from the CPython repository (the 3.7 branch), with slight modifications to allow them to work under RustPython. The current goal is to complete the standard library with as few modifications as possible. Current modifications are just temporary workarounds for bugs/missing feature within the RustPython implementation.

The first big module we are targeting is unittest, so we can leverage the CPython test suite.