Feature or enhancement

Proposal:

Over the last few years, Trio and AnyIO users have proven out several design patterns using channels as async iterables. For example, having a context manager yield an async iterable avoids the motivating problems of both PEP-533 and PEP-789.

An asyncio.Queue is almost identical to a channel-pair, especially with the .shutdown() method added in Python 3.13. I therefore propose that we add an .__aiter__ method, to more support such design patterns without subclassing or a generator helper function, with an implementation as described in #119154 (comment)

Links to previous discussion of this feature:

python/peps#3782 (review) suggested that queue.Queue could also be iterable. If we're extending this to synchronous classes I'd also include multiprocessing.Queue and multiprocessing.SimpleQueue. I'd omit multiprocessing.connection.Connection, due to the byte-level send/recv methods, and queue.SimpleQueue because without a .close() or .shutdown() method there's no clean way to shut down.

Limitations

Making Queue aiterable reaches API parity for single-producer, single-consumer patterns. In multi-producer and/or multi-consumer patterns, without a .clone() method it is the user's responsibility to shut down the queue when the last task is done. I do not propose to add .clone(), but we could include that link in the docs as an option for multi-producer patterns if desired.

Linked PRs

• gh-119154: Simplify consumers by making asyncio.Queue an asynchronous iterable #120491
• gh-119154: Simplify consumers by adding *.Queue.iter() and *.Queue.iter_nowait() #120925
• gh-119154: Simplify consumers by making queue.Queue an iterable #120503

Decision

#120925 (comment) explains the decision not to add *.Queue.iter(), and #120491 (comment) that asyncio.Queue.__aiter__ was rejected for the same reasons. Instead, the docs will show how users can write a wrapper like this.