This is an umbrella issue to capture planning and strategy discussions at the sprints.

Our draft plan has three points:

1. Add a new itertool, serialize(), which will take a non-threadsafe iterator as input and produce a new iterator that is thread-safe. Multiple threads can access the new iterator which is guaranteed to make serial (one-at-a-time) calls to the upstream iterators. This will be implemented with locks that block __next__ calls while others are pending. The implementation will not buffer calls; instead, it implements blocking to achieve serialization. If applicable, send() and throw() method calls will be forwarded as well.

2. The itertools.tee() code will have guaranteed semantics. It can take a non-threadsafe iterator from one thread as an input and provide tee objects for other threads to get reliable independent copies of the data stream. The new iterators are only thread-safe if consumed within a single thread. Internally, it buffers data to fulfill this contract.

3. Other iterators implemented in C will get only the minimal changes necessary to cause them to not crash in a free-threaded build. The edits should be made in a way that does not impact existing semantics or performance (i.e. do not damage the standard GIL build). Concurrent access is allowed to return duplicate values, skip values, or raise an exception.

Linked PRs

• gh-124397: Add itertools.serialize (name tbd) #133272
• gh-124397: Add threading.iter_locked #133908