update some more words

Author: adqm

peps/pep-0798.rst

@@ -232,7 +232,6 @@ following (though without defining or referencing the looping variable
             for i in expr:
                 yield i
 
-
 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
@@ -391,6 +390,12 @@ 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
+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
+:ref:`pep798-alternativegenexpsemantics` for more discussion.
 
 .. _pep798-examples:
 
@@ -721,9 +726,18 @@ Alternative Generator Expression Semantics
 
 Another point of discussion centered around the semantics of unpacking in
 generator expressions, particularly the relationship between the semantics of
-synchronous and asynchronous generator expressions given that the latter do not
-support ``yield from`` (see the section of :pep:`525` on Asynchronous ``yield
-from``).
+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.
 
 Several reasonable options were considered, none of which was a clear winner in
 a `poll in the Discourse thread
@@ -749,13 +763,15 @@ a `poll in the Discourse thread
    compelling practical use case for delegating to subgenerators during
    unpacking.
 
-3. Disallowing unpacking in asynchronous generator expressions until they
+3. Using ``yield from`` for unpacking in synchronous generator expressions, and
+   disallowing unpacking in asynchronous generator expressions until they
    support ``yield from``.
 
    This strategy could possibly reduce friction if asynchronous generator
-   expressions do gain support for ``yield from`` in the future, but in the
-   meantime, it would result in an even bigger discrepancy between synchronous
-   and asynchronous generator expressions than option 1.
+   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.
 
 4. Disallowing unpacking in all generator expressions.
 
@@ -765,7 +781,9 @@ a `poll in the Discourse thread
 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.
+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,