PEP 622: Rename name pattern to capture pattern (#1479)
Also make the section headings describing various types of patterns plural, e.g. "Capture patterns".
This commit is contained in:
Guido van Rossum
GitHub
parent
5aec654f9e
commit
d3bcd15cd2
64
pep-0622.rst
64
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
|
||||
|
|
|
|||
Loading…
Reference in New Issue