additional phrasing changes

Author: adqm

peps/pep-0798.rst

@@ -778,9 +778,9 @@ Beyond the proposal outlined above, the following were also considered:
    This strategy would also make unpacking in synchronous and asynchronous
    generators behave symmetrically, but it would also be more complex, enough
    so that the cost may not be worth the benefit.  As such, this PEP proposes
-   that generator expressions using the unpacking operator should not use
-   semantics similar to ``yield from`` until ``yield from`` is supported in
-   asynchronous generators more generally.
+   that asynchronous generator expressions using the unpacking operator should
+   not adopt 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
@@ -822,8 +822,9 @@ this syntax was clear and intuitive, several concerns and potential downsides
 were raised as well. This section aims to summarize those concerns.
 
 * **Overlap with existing alternatives:**
-  While the proposed syntax is arguably more concise, there are already several
-  ways to accomplish this same thing in Python.
+  While the proposed syntax represents a consistent extension to the language
+  and is likely to result in more-concise code, there are already several ways
+  to accomplish this same thing in Python.
 
 * **Function call ambiguity:**
   Expressions like ``f(*x for x in y)`` may initially appear ambiguous, as it's
@@ -839,7 +840,7 @@ were raised as well. This section aims to summarize those concerns.
   particularly complex uses even more difficult to read and understand at a
   glance.  For example, while these situations are likely rare, comprehensions
   that use unpacking in multiple ways can make it difficult to know what's
-  being unpacked and when: ``f(*(*x for *x, _ in list_of_lists))``.
+  being unpacked and when, e.g., ``f(*(*x for *x, _ in list_of_lists))``.
 
 * **Unclear limitation of scope:**
   This proposal restricts unpacking to the top level of the comprehension