diff --git a/pep-0622.rst b/pep-0622.rst index 7f6382d41..d4aa4755f 100644 --- a/pep-0622.rst +++ b/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