wording changes

Author: adqm

peps/pep-0798.rst

@@ -741,7 +741,7 @@ 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
+``.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.
 
@@ -768,16 +768,18 @@ Beyond the proposal outlined above, the following were also considered:
    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.
+   unpacking.  Generator expressions using the unpacking operator should not
+   use semantics similar to ``yield from`` until ``yield from`` is supported
+   in asynchronous generators more generally.
 
 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 by making sure
-   that any decision made at that point would be fully backwards-compatible,
-   but the utility of unpacking in that context seems to outweigh the potential
+   that any decision made at that point would be fully backwards-compatible.
+   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``.
 
@@ -791,7 +793,8 @@ 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 where unpacking in both synchronous and asynchronous
-generator expressions mirrors common ways of writing equivalent generators.
+generator expressions mirrors common ways of writing equivalent generators
+currently.
 
 As suggested above, though, this decision should be revisited in the event that
 asynchronous generators receive support for ``yield from`` in the future, in