PEP 572: Assorted fixes suggested by Rob Cliffe (#719)

Also replace the file-based example with a better one by Giampaolo Rodola'.

pep-0572.rst

@@ -95,9 +95,11 @@ save an extra level of indentation::
     match1 = pattern1.match(data)
     match2 = pattern2.match(data)
     if match1:
-        return match1.group(1)
+        result = match1.group(1)
     elif match2:
-        return match2.group(2)
+        result = match2.group(2)
+    else:
+        result = None
 
 This code tries to match ``pattern2`` even if ``pattern1`` has a match
 (in which case the match on ``pattern2`` is never used).  The more
@@ -105,11 +107,13 @@ efficient rewrite would have been::
 
     match1 = pattern1.match(data)
     if match1:
-        return match1.group(1)
+        result = match1.group(1)
     else:
         match2 = pattern2.match(data)
         if match2:
-            return match2.group(2)
+            result = match2.group(2)
+        else:
+            result = None
 
 
 Syntax and semantics
@@ -126,11 +130,14 @@ that value::
 
     # Handle a matched regex
     if (match := pattern.search(data)) is not None:
-        ...
+        # Do something with match
 
-    # A more explicit alternative to the 2-arg form of iter() invocation
-    while (value := read_next_item()) is not None:
-        ...
+    # A loop that can't be trivially rewritten using 2-arg iter()
+    while chunk := file.read(8192):
+       process(chunk)
+
+    # Reuse a value that's expensive to compute
+    [y := f(x), y**2, y**3]
 
     # Share a subexpression between a comprehension filter clause and its output
     filtered_data = [y for x in data if (y := f(x)) is not None]
@@ -275,7 +282,8 @@ Relative precedence of ``:=``
 
 The ``:=`` operator groups more tightly than a comma in all syntactic
 positions where it is legal, but less tightly than all other operators,
-including ``or``, ``and`` and ``not``.  As follows from section
+including ``or``, ``and``, ``not``, and conditional expressions
+(``A if C else B``).  As follows from section
 "Exceptional cases" above, it is never allowed at the same level as
 ``=``.  In case a different grouping is desired, parentheses should be
 used.
@@ -701,7 +709,7 @@ statements to add a means of capturing the compared value::
 This works beautifully if and ONLY if the desired condition is based on the
 truthiness of the captured value.  It is thus effective for specific
 use-cases (regex matches, socket reads that return `''` when done), and
-completely useless in more complicated cases (eg where the condition is
+completely useless in more complicated cases (e.g. where the condition is
 ``f(x) < 0`` and you want to capture the value of ``f(x)``).  It also has
 no benefit to list comprehensions.
 
@@ -724,7 +732,7 @@ above, proposals have been made for comprehension-specific solutions.
    This brings the subexpression to a location in between the 'for' loop and
    the expression. It introduces an additional language keyword, which creates
    conflicts. Of the three, ``where`` reads the most cleanly, but also has the
-   greatest potential for conflict (eg SQLAlchemy and numpy have ``where``
+   greatest potential for conflict (e.g. SQLAlchemy and numpy have ``where``
    methods, as does ``tkinter.dnd.Icon`` in the standard library).
 
 2. ``with NAME = EXPR``::
@@ -906,7 +914,7 @@ ruled::
     mylast = mylast[1]
     yield mylast[0]
 
-is a vast improvment over the briefer::
+is a vast improvement over the briefer::
 
     yield (mylast := mylast[1])[0]