PEP 642: Use correct terminology for new PEG parser (#1687)
Also links to the WIP reference implementation.
This commit is contained in:
Nick Coghlan
GitHub
parent
732d8ff3a9
commit
0265bd00d5
65
pep-0642.rst
65
pep-0642.rst
|
|
@ -33,10 +33,10 @@ pattern syntax:
|
|||
* Literal patterns and value patterns are combined into a single new
|
||||
pattern type: "constraint patterns"
|
||||
* Constraint patterns use `?` as a prefix marker on an otherwise arbitrary
|
||||
atomic expression: `?EXPR`
|
||||
primary expression: `?EXPR`
|
||||
* There is no special casing of the `None`, `True`, or `False` literals
|
||||
* The constraint expression may be omitted to give a non-binding wildcard pattern
|
||||
* Mapping patterns change to allow arbitrary atoms as keys
|
||||
* Mapping patterns change to allow arbitrary primary expressions as keys
|
||||
* Attempting to use a dotted name as a match pattern is a syntax error rather
|
||||
than implying a value constraint
|
||||
* Attempting to use a literal as a match pattern is a syntax error rather
|
||||
|
|
@ -138,8 +138,8 @@ Wildcard patterns change their syntactic marker from `_` to `?`.
|
|||
Literal patterns and value patterns are replaced by constraint
|
||||
patterns.
|
||||
|
||||
Mapping patterns change to allow arbitrary atoms for keys, rather than being
|
||||
restricted to literal patterns or value patterns.
|
||||
Mapping patterns change to allow arbitrary primary expressions for keys, rather
|
||||
than being restricted to literal patterns or value patterns.
|
||||
|
||||
|
||||
Wildcard patterns
|
||||
|
|
@ -164,11 +164,11 @@ Constraint patterns
|
|||
|
||||
Constraint patterns use the following simplified syntax::
|
||||
|
||||
constraint_pattern: '?' EXPR
|
||||
constraint_pattern: '?' primary
|
||||
|
||||
The constraint expression is an arbitrary atomic expression - it can be a
|
||||
The constraint expression is an arbitrary primary expression - it can be a
|
||||
simple name, a dotted name lookup, a literal, a function call, or any other
|
||||
atomic expression.
|
||||
primary expression.
|
||||
|
||||
If this PEP were to be adopted in preference to PEP 634, then all literal and
|
||||
value patterns would instead be written as constraint patterns::
|
||||
|
|
@ -240,7 +240,7 @@ value patterns with constraint patterns::
|
|||
mapping_pattern: '{' [items_pattern] '}'
|
||||
items_pattern: ','.key_value_pattern+ ','?
|
||||
key_value_pattern:
|
||||
| atom ':' or_pattern
|
||||
| primary ':' or_pattern
|
||||
| '**' capture_pattern
|
||||
|
||||
However, the constraint marker prefix is not needed in this case, as the fact
|
||||
|
|
@ -587,13 +587,15 @@ Accordingly, the proposal was simplified to omit the marker prefix from mapping
|
|||
pattern keys.
|
||||
|
||||
|
||||
Restricting the permitted atoms in constraint patterns and mapping pattern keys
|
||||
-------------------------------------------------------------------------------
|
||||
Restricting permitted expressions in constraint patterns and mapping pattern keys
|
||||
---------------------------------------------------------------------------------
|
||||
|
||||
While it's entirely technical possible to restrict the kinds of expressions
|
||||
permitted in constraint patterns and mapping pattern keys to just attribute
|
||||
lookups (as PEP 634 does), there isn't any clear runtime value in doing so,
|
||||
so the PEP proposes allowing any kind of atom.
|
||||
so the PEP proposes allowing any kind of primary expression (primary
|
||||
expressions are an existing node type in the grammar that includes things like
|
||||
literals, names, attribute lookups, function calls, container subscripts, etc).
|
||||
|
||||
While PEP 635 does emphasise several times that literal patterns and value
|
||||
patterns are not full expressions, it doesn't ever articulate a concrete benefit
|
||||
|
|
@ -606,10 +608,11 @@ that just returned their argument) to express the behaviour they wanted before
|
|||
the language definition was finally updated to allow arbitrary expressions and
|
||||
let users make their own decisions about readability.
|
||||
|
||||
The comparable situation for PEP 634 is that arbitrary expressions are
|
||||
technically supported in value patterns, they just require an awkward workaround
|
||||
where all the values to match need to be specified in a helper class that is
|
||||
placed before the match statement::
|
||||
The situation in PEP 634 that bears a resemblance to the situation with decorator
|
||||
expressions is that arbitrary expressions are technically supported in value
|
||||
patterns, they just require an awkward workaround where all the values to
|
||||
match need to be specified in a helper class that is placed before the match
|
||||
statement::
|
||||
|
||||
# Allowing arbitrary match targets with PEP 634's value pattern syntax
|
||||
class mt:
|
||||
|
|
@ -625,23 +628,28 @@ supporting arbitrary value constraints from the start::
|
|||
case ?func():
|
||||
... # Handle the case where 'expr == func()'
|
||||
|
||||
Whether actually doing that or not is a good idea would be a topic for style
|
||||
guides and code linters, not the language compiler.
|
||||
Whether actually writing that kind of code is a good idea would be a topic for
|
||||
style guides and code linters, not the language compiler.
|
||||
|
||||
In particular, if static analysers can't follow certain kinds of dynamic checks,
|
||||
then they can limit the permitted expressions at analysis time, rather than the
|
||||
compiler restricting them at compile time.
|
||||
|
||||
|
||||
Reference Implementation
|
||||
========================
|
||||
|
||||
A reference implementation for this PEP is being derived from Brandt Bucher's
|
||||
reference implementation for PEP 634 [3_].
|
||||
A reference implementation for this PEP [3_] is being derived from Brandt
|
||||
Bucher's reference implementation for PEP 634 [4_].
|
||||
|
||||
Relative to the text of this PEP, the draft reference implementation will
|
||||
retain literal patterns as implemented for PEP 634 (as this PEP only removes
|
||||
Relative to the text of this PEP, the draft reference implementation currently
|
||||
retains literal patterns as implemented for PEP 634 (This PEP only removes
|
||||
them as redundant given constraint patterns, it doesn't inherently conflict with
|
||||
them). Value patterns, wildcard patterns, and mapping patterns are being updated
|
||||
them, and both the tutorial in PEP 636 and the pattern matching test suite
|
||||
suggest that keeping literal patterns might be worthwhile even if the spelling
|
||||
of value matching patterns is changed).
|
||||
|
||||
Value patterns, wildcard patterns, and mapping patterns are being updated
|
||||
to follow this PEP rather than PEP 634.
|
||||
|
||||
|
||||
|
|
@ -665,7 +673,10 @@ References
|
|||
.. [2] Declined pull request proposing to list this as a Rejected Idea in PEP 622
|
||||
https://github.com/python/peps/pull/1564
|
||||
|
||||
.. [3] PEP 634 reference implementation
|
||||
.. [3] In-progress reference implementation for this PEP
|
||||
https://github.com/ncoghlan/cpython/tree/pep-642-constraint-patterns
|
||||
|
||||
.. [4] PEP 634 reference implementation
|
||||
https://github.com/python/cpython/pull/22917
|
||||
|
||||
|
||||
|
|
@ -708,9 +719,9 @@ Notation used beyond standard EBNF is as per PEP 534:
|
|||
|
||||
capture_pattern: NAME !('.' | '(' | '=')
|
||||
|
||||
wildcard_pattern: '?'
|
||||
constraint_pattern: '?' primary
|
||||
|
||||
constraint_pattern: '?' atom
|
||||
wildcard_pattern: '?'
|
||||
|
||||
group_pattern: '(' pattern ')'
|
||||
|
||||
|
|
@ -725,12 +736,14 @@ Notation used beyond standard EBNF is as per PEP 534:
|
|||
mapping_pattern: '{' [items_pattern] '}'
|
||||
items_pattern: ','.key_value_pattern+ ','?
|
||||
key_value_pattern:
|
||||
| atom ':' pattern
|
||||
| primary ':' pattern
|
||||
| double_star_pattern
|
||||
double_star_pattern: '**' capture_pattern
|
||||
|
||||
class_pattern:
|
||||
| name_or_attr '(' [pattern_arguments ','?] ')'
|
||||
attr: name_or_attr '.' NAME
|
||||
name_or_attr: attr | NAME
|
||||
pattern_arguments:
|
||||
| positional_patterns [',' keyword_patterns]
|
||||
| keyword_patterns
|
||||
|
|
|
|||
Loading…
Reference in New Issue