PEP 622: Fix various nits reported by the SC

pep-0622.rst

@@ -55,7 +55,7 @@ proposed syntax and semantics.
 Overview
 ========
 
-Since patterns are a new syntactical category with their own rules
+Since patterns are a new syntactic category with their own rules
 and special cases, and since they mix input (given values) and output
 (captured variables) in novel ways, they require a bit of getting used
 to. It is the experience of the authors that this happens quickly when
@@ -285,7 +285,7 @@ Syntax and Semantics
 Patterns
 --------
 
-The **pattern** is a new syntactical construct, that could be considered a loose
+The **pattern** is a new syntactic construct, that could be considered a loose
 generalization of assignment targets. The key properties of a pattern are what
 types and shapes of subjects it accepts, what variables it captures and how
 it extracts them from the subject. For example the pattern ``[a, b]`` matches
@@ -371,7 +371,6 @@ this section are there for helping the reader, not as a full specification.
 
 We propose that the match operation should be a statement, not an expression.
 Although in
-
 many languages it is an expression, being a statement better suits the general
 logic of Python syntax. See `rejected ideas`_ for more discussion.
 The allowed patterns are described in detail below in the `patterns`_
@@ -654,7 +653,7 @@ Simplified syntax::
 
 Mapping pattern is a generalization of iterable unpacking to mappings.
 Its syntax is similar to dictionary display but each key and value are
-patterns ``"{" (pattern ":" pattern)+ "}"``. A ``**name`` pattern is also
+patterns ``"{" (pattern ":" pattern)+ "}"``. A ``**rest`` pattern is also
 allowed, to extract the remaining items.  Only literal and constant value
 patterns are allowed in key positions::
 
@@ -700,7 +699,7 @@ Simplified syntax::
 A class pattern provides support for destructuring arbitrary objects.
 There are two possible ways of matching on object attributes: by position
 like ``Point(1, 2)``, and by name like ``Point(x=1, y=2)``. These
-two can be combined, but positional match cannot follow a match by name.
+two can be combined, but a positional match cannot follow a match by name.
 Each item in a class pattern can be an arbitrary pattern. A simple
 example::
 
@@ -735,7 +734,7 @@ Combining multiple patterns (OR patterns)
 
 Multiple alternative patterns can be combined into one using ``|``. This means
 the whole pattern matches if at least one alternative matches.
-Alternatives are tried from left to right and have short-circuit property,
+Alternatives are tried from left to right and have a short-circuit property,
 subsequent patterns are not tried if one matched. Examples::
 
   match something:
@@ -858,7 +857,7 @@ The procedure is as following:
   sub-patterns succeed, the overall class pattern match succeeds.
 
 * If there are match-by-position items and the class has a
-  ``__match_args__``, the item at position ``i``
+  ``__match_args__`` attribute, the item at position ``i``
   is matched against the value looked up by attribute
   ``__match_args__[i]``. For example, a pattern ``Point2D(5, 8)``,
   where ``Point2D.__match_args__ == ["x", "y"]``, is translated
@@ -1146,7 +1145,7 @@ Note about constants
 The fact that a capture pattern is always an assignment target may create unwanted
 consequences when a user by mistake tries to "match" a value against
 a constant instead of using the constant value pattern. As a result, at
-runtime such match will always succeed and moreover override the value of
+runtime such a match will always succeed and moreover override the value of
 the constant. It is important therefore that static type checkers warn about
 such situations. For example::
 
@@ -1224,7 +1223,7 @@ desire to break or deprecate.
 The difference between hard and soft keywords is that hard keywords
 are *always* reserved words, even in positions where they make no
 sense (e.g. ``x = class + 1``), while soft keywords only get a special
-meaning in context.  Since our parser backtracks, that means that on
+meaning in context.  Since PEP 617 the parser backtracks, that means that on
 different attempts to parse a code fragment it could interpret a soft
 keyword differently.
 
@@ -1340,12 +1339,12 @@ in a cleaner and more maintainable architecture. These use cases tend to
 be characterized by a number of features:
 
 * Algorithms which cut across traditional lines of data encapsulation. If an
-  algorithm is processing heterogenous elements of different types (such as
+  algorithm is processing heterogeneous elements of different types (such as
   evaluating or transforming an abstract syntax tree, or doing algebraic
   manipulation of mathematical symbols), forcing the user to implement
   the algorithm as individual methods on each element type results in
   logic that is smeared across the entire codebase instead of being neatly
-  localized in once place.
+  localized in one place.
 * Program architectures where the set of possible data types is relatively
   stable, but there is an ever-expanding set of operations to be performed
   on those data types. Doing this in a strict OOP fashion requires constantly
@@ -2112,7 +2111,7 @@ Pattern Utility Library
 -----------------------
 
 Both of the previous ideas would be accompanied by a new Python standard
-library module which would contain a rich set of exotic and useful matchers.
+library module which would contain a rich set of useful matchers.
 However, it it not really possible to implement such a library without
 adopting one of the extended pattern proposals given in the previous sections,
 so this idea is also deferred.