diff --git a/peps/pep-0798.rst b/peps/pep-0798.rst index 400aa6f3097..78a8e169d91 100644 --- a/peps/pep-0798.rst +++ b/peps/pep-0798.rst @@ -3,11 +3,35 @@ Title: Unpacking in Comprehensions Author: Adam Hartz , Erik Demaine Sponsor: Jelle Zijlstra Discussions-To: https://discuss.python.org/t/99435 -Status: Draft +Status: Accepted Type: Standards Track Created: 19-Jul-2025 Python-Version: 3.15 -Post-History: `16-Oct-2021 `__, `22-Jun-2025 `__, `19-Jul-2025 `__ +Post-History: + `16-Oct-2021 `__, + `22-Jun-2025 `__, + `19-Jul-2025 `__, +Resolution: `03-Nov-2025 `__ + +.. note:: + The Steering Council accepts this PEP with one modification: we require that + both synchronous and asynchronous generator expressions use explicit loops + rather than yield from for unpacking operations. + + The Steering Council believes that simplicity and consistency are paramount + here. The delegation behaviour provided by ``yield from`` adds semantic + complexity for advanced use cases involving ``.send(),`` ``.throw()``, and + ``.close()`` that are rarely relevant when writing comprehensions. We don’t + believe that developers writing comprehensions should have to think about + the differences between sync and async generator semantics or about generator + delegation protocols. We firmly believe that the mental model should be as + simple as possible and as symmetric as possible between all kinds of + comprehensions. The straightforward semantics of explicit loops provide a + uniform mental model that works the same way regardless of context, and also + provides better parity with the function-like versions, such as + ``itertools.chain.from_iterable``. For the rare cases where someone actually + needs delegation behaviour, the Steering Council believes they should use an + explicit generator function with ``yield from`` rather than a comprehension. Abstract