revert to original proposal's semantics for genexps

Author: adqm

peps/pep-0798.rst

@@ -217,26 +217,33 @@ Semantics: Generator Expressions
 Generator expressions using the unpacking syntax should form new generators
 producing values from the concatenation of the iterables given by the
 expressions.  Specifically, the behavior is defined to be equivalent to the
-following (though without defining or referencing the looping variable
-``i``)::
+following::
 
-    # equivalent to generator = (*expr for x in it)
+    # equivalent to g = (*expr for x in it)
     def generator():
         for x in it:
-            for i in expr:
-                yield i
+            yield from expr
+
+    g = generator()
+
+Since ``yield from`` is not allowed inside of async generators (see the section
+of :pep:`525` on Asynchronous ``yield from``), the equivalent for ``(*expr
+async for x in ait())`` is more like the following (though of course this new
+form should not define or reference the looping variable ``i``)::
 
-    # equivalent to generator = (*expr async for x in ait())
+    # equivalent to g = (*expr async for x in ait())
     async def generator():
         async for x in ait():
             for i in expr:
                 yield i
 
+    g = generator()
+
 The specifics of these semantics should be revisited in the future,
 particularly if async generators receive support for ``yield from`` (in which
-case both forms may wish to be changed to make use of ``yield from`` instead of
-an explicit loop).  See :ref:`pep798-alternativegenexpsemantics` for more
-discussion.
+case the async variant may wish to be changed to make use of ``yield from``
+instead of an explicit loop).  See :ref:`pep798-alternativegenexpsemantics` for
+more discussion.
 
 Interaction with Assignment Expressions
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -255,8 +262,7 @@ form, ``y`` will be bound in the containing scope instead of locally::
 
     def generator():
         for i in (0, 2, 4):
-            for j in (y := [i, i+1]):
-                yield j
+            yield from (y := [i, i+1])
 
 In this example, the subexpression ``(y := [i, i+1])`` is evaluated exactly
 three times before the generator is exhausted: just after assigning ``i`` in
@@ -390,11 +396,11 @@ in comprehensions would raise a ``SyntaxError``, or that relied on the
 particular phrasing of any of the old error messages being replaced, which we
 expect to be rare.
 
-One related concern is that a hypotehtical future decision to change the
-semantics of generator expressions to make use of ``yield from`` during
+One related concern is that a hypothetical future decision to change the
+semantics of async generator expressions to make use of ``yield from`` during
 unpacking (delegating to generators that are being unpacked) would be not be
 backwards-compatible because it would affect the behavior of the resulting
-generators when used with ``.send()``, ``.throw()``, and ``.close()``.  See
+generators when used with ``.asend()``, ``.athrow()``, and ``.aclose()``.  See
 :ref:`pep798-alternativegenexpsemantics` for more discussion.
 
 .. _pep798-examples:
@@ -730,37 +736,38 @@ synchronous and asynchronous generator expressions given that async generators
 do not support ``yield from`` (see the section of :pep:`525` on Asynchronous
 ``yield from``).
 
-The core question centered around whether sync and/or async generator
-expressions should use ``yield from`` (or an equivalent) when unpacking, as
-opposed to an explicit loop.  The main difference between these options is
-whether the resulting generator delegates to the objects being unpacked (see
-:pep:`380`), which would affect the behavior of these generator expressions
-when used with ``.send()``, ``.throw()``, and ``.close()``, in the case where
-the objects being unpacked are themselves generators, which appears to be a
-rare situation.
+The core question centered around whether sync and async generator expressions
+should use ``yield from`` (or an equivalent) when unpacking, as opposed to an
+explicit loop.  The main difference between these options is whether the
+resulting generator delegates to the objects being unpacked (see :pep:`380`),
+which would affect the behavior of these generator expressions when used with
+``.send()/.asend()``, ``.throw()/.athrow()``, and ``.close()/.aclose()``, in
+the case where the objects being unpacked are themselves generators, which
+is unlikely to be a common use case.
 
 Several reasonable options were considered, none of which was a clear winner in
 a `poll in the Discourse thread
-<https://discuss.python.org/t/pep-798-unpacking-in-comprehensions/99435/33>`__:
+<https://discuss.python.org/t/pep-798-unpacking-in-comprehensions/99435/33>`__.
+Beyond the proposal outlined above, the following were also considered:
 
-1. Using ``yield from`` for unpacking in synchronous generator expressions but
-   not in asynchronous generator expressions (as proposed in the original draft
-   of this PEP).
+1. Using explicit loops for both synchronous and asynchronous generator
+   expressions.
 
-   This strategy would have allowed unpacking in generator expressions to
-   closely mimic a popular way of writing generators that perform this
-   operation (using ``yield from``), but it would also have created an
-   asymmetry between synchronous and asynchronous versions, and also between
-   this new syntax and ``itertools.chain`` and the double-loop version.
+   This strategy would have resulted in a symmetry between synchronous and
+   asynchronous generator expressions but would have prevented a
+   potentially-useful tool by disallowing delegation in the case of synchronous
+   generator expressions.  Moreover, the existing asymmetry between synchronous
+   and asynchronous generators mitigates concerns about asymmetry of the
+   unpacking operator within generator expressions.
 
 2. Using ``yield from`` for unpacking in synchronous generator expressions and
    mimicking the behavior of ``yield from`` for unpacking in async generator
    expressions.
 
    This strategy would also make unpacking in synchronous and asynchronous
-   generators behave similarly, but it would also be more complex, enough so
-   that the cost may not be worth the benefit, particularly in the absence of a
-   compelling practical use case for delegating to subgenerators during
+   generators behave symmetrically, but it would also be more complex, enough
+   so that the cost may not be worth the benefit, particularly in the absence
+   of a compelling practical use case for delegating to subgenerators during
    unpacking.
 
 3. Using ``yield from`` for unpacking in synchronous generator expressions, and
@@ -770,25 +777,26 @@ a `poll in the Discourse thread
    This strategy could possibly reduce friction if asynchronous generator
    expressions do gain support for ``yield from`` in the future by making sure
    that any decision made at that point would be fully backwards-compatible,
-   but in the meantime, it would result in an even bigger discrepancy between
-   synchronous and asynchronous generator expressions than option 1.
+   but the utility of unpacking in that context seems to outweigh the potential
+   downside of a backwards-incompatible change in the future if aync generator
+   expressions do receive support for ``yield from``.
 
 4. Disallowing unpacking in all generator expressions.
 
    This would retain symmetry between the two cases, but with the downside of
    losing a very expressive form.
 
+
 Each of these options (including the one presented in this PEP) has its
 benefits and drawbacks, with no option being clearly superior on all fronts;
 but the semantics proposed in :ref:`pep798-genexpsemantics` represent a
-reasonable compromise by allowing exactly the same kind of unpacking in
-synchronous and asynchronous generator expressions and retaining an existing
-property of generator expressions (that they do not
-
-As suggested above, this decision should be revisited in the event that
-asynchronous generators receive support for ``yield from`` in the future,
-in which case the ability to delegate to subgenerators during unpacking
-could be added without significant cost.
+reasonable compromise where unpacking in both synchronous and asynchronous
+generator expressions mirrors common ways of writing equivalent generators.
+
+As suggested above, though, this decision should be revisited in the event that
+asynchronous generators receive support for ``yield from`` in the future, in
+which case adjusting the semantics of unpacking in async generator expressions
+to use ``yield from`` should be considered.
 
 
 Concerns and Disadvantages