PEP 622: Rename name pattern to capture pattern (#1479)

Also make the section headings describing various types of patterns plural, e.g. "Capture patterns".

pep-0622.rst

@@ -143,7 +143,7 @@ A simplified, approximate grammar for the proposed syntax is::
   or_pattern: closed_pattern ('|' closed_pattern)*
   closed_pattern:
       | literal_pattern
-      | name_pattern
+      | capture_pattern
       | constant_pattern
       | sequence_pattern
       | mapping_pattern
@@ -183,7 +183,7 @@ statements. Note that unlike for the previously proposed ``switch`` statement,
 the pre-computed dispatch dictionary semantics does not apply here.
 
 There is no ``default`` or ``else`` case - instead the special wildcard
-``_`` can be used (see the section on `name_pattern`_) as a final
+``_`` can be used (see the section on `capture_pattern`_) as a final
 'catch-all' pattern.
 
 Name bindings made during a successful pattern match outlive the executed suite
@@ -210,8 +210,8 @@ building blocks. The following patterns are supported:
 
 .. _literal_pattern:
 
-Literal Pattern
+Literal Patterns
-~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~
 
 A literal pattern consists of a simple literal like a string, a number,
 a Boolean literal (``True`` or ``False``), or ``None``::
@@ -251,12 +251,12 @@ are supported. F-strings are not allowed (since in general they are not
 really literals).
 
 
-.. _name_pattern:
+.. _capture_pattern:
 
-Name Pattern
+Capture Patterns
-~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~
 
-A name pattern serves as an assignment target for the matched expression::
+A capture pattern serves as an assignment target for the matched expression::
 
   match greeting:
       case "":
@@ -264,7 +264,7 @@ A name pattern serves as an assignment target for the matched expression::
       case name:
           print(f"Hi {name}!")
 
-A name pattern always succeeds. A name pattern appearing in a scope makes
+A capture pattern always succeeds. A capture pattern appearing in a scope makes
 the name local to that scope. For example, using ``name`` after the above
 snippet may raise ``UnboundLocalError`` rather than ``NameError``, if
 the ``""`` case clause was taken::
@@ -278,7 +278,7 @@ the ``""`` case clause was taken::
       ...                  # but works fine if greeting was not empty
 
 While matching against each case clause, a name may be bound at most
-once, having two name patterns with coinciding names is an error. An
+once, having two capture patterns with coinciding names is an error. An
 exception is made for the special single underscore (``_``) name; in
 patterns, it's a wildcard that *never* binds::
 
@@ -299,14 +299,14 @@ literals, not names.
 
 .. _constant_value_pattern:
 
-Constant Value Pattern
+Constant Value Patterns
-~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~
 
 This is used to match against constants and enum values.
 Every dotted name in a pattern is looked up using normal Python name
 resolution rules, and the value is used for comparison by equality with
 the matching expression (same as for literals). As a special case to avoid
-ambiguity with name patterns, simple names must be prefixed with a dot to be
+ambiguity with capture patterns, simple names must be prefixed with a dot to be
 considered a reference::
 
   from enum import Enum
@@ -332,8 +332,8 @@ for constant value pattern.
 
 .. _sequence_pattern:
 
-Sequence Pattern
+Sequence Patterns
-~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~
 
 A sequence pattern follows the same semantics as unpacking assignment.
 Like unpacking assignment, both tuple-like and list-like syntax can be
@@ -363,8 +363,8 @@ example:
 
 .. _mapping_pattern:
 
-Mapping Pattern
+Mapping Patterns
-~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~
 
 Mapping pattern is a generalization of iterable unpacking to mappings.
 Its syntax is similar to dictionary display but each key and value are
@@ -398,8 +398,8 @@ were already present when the ``match`` block was entered.
 
 .. _class_pattern:
 
-Class Pattern
+Class Patterns
-~~~~~~~~~~~~~
+~~~~~~~~~~~~~~
 
 A class pattern provides support for destructuring arbitrary objects.
 There are two possible ways of matching on object attributes: by position
@@ -514,7 +514,7 @@ Named sub-patterns
 
 It is often useful to match a sub-pattern *and* to bind the corresponding
 value to a name. For example, it can be useful to write more efficient
-matches, or simply to avoid repetition. To simplify such cases, a name pattern
+matches, or simply to avoid repetition. To simplify such cases, a capture pattern
 can be combined with another arbitrary pattern using named sub-patterns of
 the form ``name := pattern``. For example::
 
@@ -522,7 +522,7 @@ the form ``name := pattern``. For example::
       case Line(start := Point(x, y), end) if start == end:
           print(f"Zero length line at {x}, {y}")
 
-Note that the name pattern used in the named sub-pattern can be used in
+Note that the capture pattern used in the named sub-pattern can be used in
 the match suite, or after the match statement.  However, the name will
 *only* be bound if the sub-pattern succeeds.  Another example::
 
@@ -885,7 +885,7 @@ variables. For example::
 Note about constants
 --------------------
 
-The fact that name pattern is always an assignment target may create unwanted
+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
@@ -1181,10 +1181,10 @@ Alternatives for constant value pattern
 
 This is probably the trickiest item. Matching against some pre-defined
 constants is very common, but the dynamic nature of Python also makes it
-ambiguous with name patterns. Four other alternatives were considered:
+ambiguous with capture patterns. Four other alternatives were considered:
 
 * Use some implicit rules. For example if a name was defined in the global
-  scope, then it refers to a constant, rather than represents a name pattern::
+  scope, then it refers to a constant, rather than represents a capture pattern::
 
     FOO = 1
     value = 0
@@ -1199,7 +1199,7 @@ ambiguous with name patterns. Four other alternatives were considered:
   defines an unrelated coinciding name before the match statement.
 
 * Use a rule based on the case of a name. In particular, if the name
-  starts with a lowercase letter it would be a name pattern, while if
+  starts with a lowercase letter it would be a capture pattern, while if
   it starts with uppercase it would refer to a constant::
 
     FOO = 1
@@ -1253,7 +1253,7 @@ ambiguous with name patterns. Four other alternatives were considered:
   narrow use-case is probably an overkill.
 
 * There was also on idea to make lookup semantics the default, and require
-  ``$`` to be used in name patterns::
+  ``$`` to be used in capture patterns::
 
     FOO = 1
     value = 0
@@ -1264,7 +1264,7 @@ ambiguous with name patterns. Four other alternatives were considered:
         case $BAR:  # This would be matched
             ...
 
-  But the name patterns are more common in typical code, so having special
+  But the capture patterns are more common in typical code, so having special
   syntax for common case would be weird.
 
 In the end, these alternatives were rejected because of the mentioned drawbacks.
@@ -1556,7 +1556,7 @@ value was equal to the value previously bound. If the value was not equal,
 the match would fail.
 
 However, there are a number of subtleties involved with mixing load-store
-semantics for name patterns. For the moment, we decided to make repeated
+semantics for capture patterns. For the moment, we decided to make repeated
 use of names within the same pattern an error; we can always relax this
 restriction later without affecting backwards compatibility.
 
@@ -1731,14 +1731,14 @@ Other notation used beyond standard EBNF:
   pattern: NAME ':=' or_pattern | or_pattern
   or_pattern: '|'.closed_pattern+
   closed_pattern:
-      | name_pattern
+      | capture_pattern
       | literal_pattern
       | constant_pattern
       | group_pattern
       | sequence_pattern
       | mapping_pattern
       | class_pattern
-  name_pattern: NAME !('.' | '(' | '=')
+  capture_pattern: NAME !('.' | '(' | '=')
   literal_pattern:
       | signed_number !('+' | '-')
       | signed_number '+' NUMBER
@@ -1762,10 +1762,10 @@ Other notation used beyond standard EBNF:
   values_pattern: ','.value_pattern+ ','?
   items_pattern: ','.key_value_pattern+ ','?
   keyword_pattern: NAME '=' or_pattern
-  value_pattern: '*' name_pattern | pattern
+  value_pattern: '*' capture_pattern | pattern
   key_value_pattern:
       | (literal_pattern | constant_pattern) ':' or_pattern
-      | '**' name_pattern
+      | '**' capture_pattern
 
 
 Copyright