PEP 635: Small tweaks/fixes to Class pattern and History

pep-0635.rst

@@ -1040,7 +1040,7 @@ an object lacks an attribute specified by the pattern, the match fails.
   both attributes and assign them to ``x`` and ``y``, respectively.  The data
   flow from left to right seems unusual, but is in line with mapping patterns
   and has precedents such as assignments via ``as`` in *with*- or
-  *import*-statements.
+  *import*-statements (and indeed AS patterns).
 
   Naming the attributes in question explicitly will be mostly used for more
   complex cases where the positional form (below) is insufficient.
@@ -1051,7 +1051,7 @@ an object lacks an attribute specified by the pattern, the match fails.
   This is particularly handy for smaller objects or instances of data classes,
   where the attributes of interest are rather obvious and often have a
   well-defined ordering.  In a way, ``__match_args__`` is similar to the
-  declaration of formal parameters, which allows to call functions with
+  declaration of formal parameters, which allows calling functions with
   positional arguments rather than naming all the parameters.
 
 
@@ -1075,7 +1075,7 @@ sending and that for receiving 'data' are virtually identical.
 Using the same syntax for reading and writing, l- and r-values, or
 construction and de-construction is widely accepted for its benefits in
 thinking about data, its flow and manipulation.  This equally extends to
-the explicit construction of instances, where class patterns ``c(p, q)``
+the explicit construction of instances, where class patterns ``C(p, q)``
 deliberately mirror the syntax of creating instances.
 
 
@@ -1084,12 +1084,12 @@ The proposal was to combine patterns with type annotations::
 
   match x:
       case [a: int, b: str]: print(f"An int {a} and a string {b}:)
-      case [a: int, b: int, c: int]: print(f"Three ints", a, b, c)
+      case [a: int, b: int, c: int]: print("Three ints", a, b, c)
       ...
 
-This idea has a lot of problems. For one, the colon can only
-be used inside of brackets or parens, otherwise the syntax becomes
-ambiguous. And because Python disallows ``isinstance()`` checks
+This idea has a lot of problems.  For one, the colon can only
+be used inside of brackets or parentheses, otherwise the syntax becomes
+ambiguous.  And because Python disallows ``isinstance()`` checks
 on generic types, type annotations containing generics will not
 work as expected.
 
@@ -1112,11 +1112,11 @@ same effect.
 Using modern syntax, a depth-first tree traversal would then be written as
 follows::
 
-  def traverse_tree(node):
+  def traverse(node):
       node match:
           case Node(left, right):
-              DFS(left)
-              DFS(right)
+              traverse(left)
+              traverse(right)
           case Leaf(value):
               handle(value)
 
@@ -1157,7 +1157,7 @@ along the lines of (Standard ML)::
     | fib n = fib (n-1) + fib (n-2)
 
 Even though such a strict separation of case clauses into independent
-functions does not make sense in Python, we find that patterns share many
+functions does not apply in Python, we find that patterns share many
 syntactic rules with parameters, such as binding arguments to unqualified
 names only or that variable/parameter names must not be repeated for
 a particular pattern/function.