匹配语句

表面语法

match_stmt: "match" subject_expr ':' NEWLINE INDENT case_block+ DEDENT
subject_expr:
    | star_named_expression ',' star_named_expressions?
    | named_expression
case_block: "case" (guarded_pattern | open_pattern) ':' block

guarded_pattern: closed_pattern 'if' named_expression

open_pattern:
    | as_pattern
    | or_pattern

closed_pattern:
    | wildcard_pattern
    | group_pattern
    | structural_constraint

抽象语法

Match(expr subject, match_case* cases)
match_case = (pattern pattern, expr? guard, stmt* body)

规则star_named_expression、star_named_expressions、named_expression和block是标准 Python 语法的一部分。

开放模式是指由多个标记组成的模式，并且不一定会以结束分隔符结尾（例如，__ as x、int() | bool()）。为了避免人类读者产生歧义，它们的用法仅限于顶级模式和组模式（即用括号括起来的模式）。

封闭模式是指由单个标记组成的模式（即__），或者其语法中需要包含结束分隔符（例如，[as x, as y]、object{.x as x, .y as y}）。

与PEP 634一样，match和case关键字是软关键字，即它们在其他语法上下文中不是保留字（包括如果预期位置没有冒号时，在行的开头）。这意味着它们仅在匹配语句或 case 块的一部分时才被识别为关键字，并且允许在所有其他上下文中用作变量或参数名称。

与PEP 634不同，模式在抽象语法树中被明确定义为一种新的节点类型 - 即使表面语法与现有的表达式节点共享，解析器也会发出不同的抽象节点。

作为上下文，match_stmt是表面语法中compound_statement的新替代方案，而Match是抽象语法中stmt的新替代方案。

模式

模式的顶级表面语法如下

open_pattern: # Pattern may use multiple tokens with no closing delimiter
    | as_pattern
    | or_pattern

as_pattern: [closed_pattern] pattern_as_clause

or_pattern: '|'.simple_pattern+

simple_pattern: # Subnode where "as" and "or" patterns must be parenthesised
    | closed_pattern
    | value_constraint

closed_pattern: # Require a single token or a closing delimiter in pattern
    | wildcard_pattern
    | group_pattern
    | structural_constraint

如上所述，开放模式的用法仅限于顶级 case 子句以及在组模式中用括号括起来时。

模式的抽象语法明确指示哪些元素是子模式，哪些元素是子表达式或标识符

pattern = MatchAlways
     | MatchValue(matchop op, expr value)
     | MatchSequence(pattern* patterns)
     | MatchMapping(expr* keys, pattern* patterns)
     | MatchAttrs(expr cls, identifier* attrs, pattern* patterns)
     | MatchClass(expr cls, pattern* patterns, identifier* extra_attrs, pattern* extra_patterns)

     | MatchRestOfSequence(identifier? target)
     -- A NULL entry in the MatchMapping key list handles capturing extra mapping keys

     | MatchAs(pattern? pattern, identifier target)
     | MatchOr(pattern* patterns)

as_pattern: [closed_pattern] pattern_as_clause
pattern_as_clause: 'as' pattern_capture_target
pattern_capture_target: !"__" NAME !('.' | '(' | '=')

MatchAs(pattern? pattern, identifier target)

or_pattern: '|'.simple_pattern+

simple_pattern: # Subnode where "as" and "or" patterns must be parenthesised
    | closed_pattern
    | value_constraint

MatchOr(pattern* patterns)

value_constraint:
    | eq_constraint
    | id_constraint

eq_constraint: '==' closed_expr
id_constraint: 'is' closed_expr

closed_expr: # Require a single token or a closing delimiter in expression
    | primary
    | closed_factor

closed_factor: # "factor" is the main grammar node for these unary ops
    | '+' primary
    | '-' primary
    | '~' primary

MatchValue(matchop op, expr value)
matchop = EqCheck | IdCheck

# Literal patterns
match number:
    case == 0:
        print("Nothing")
    case == 1:
        print("Just one")
    case == 2:
        print("A couple")
    case == -1:
        print("One less than nothing")
    case == (1-1j):
        print("Good luck with that...")

# Additional literal patterns
match value:
    case == True:
        print("True or 1")
    case == False:
        print("False or 0")
    case == None:
        print("None")
    case == "Hello":
        print("Text 'Hello'")
    case == b"World!":
        print("Binary 'World!'")

# Matching by identity rather than equality
SENTINEL = object()
match value:
    case is True:
        print("True, not 1")
    case is False:
        print("False, not 0")
    case is None:
        print("None, following PEP 8 comparison guidelines")
    case is ...:
        print("May be useful when writing __getitem__ methods?")
    case is SENTINEL:
        print("Matches the sentinel by identity, not just value")

# Matching against variables and attributes
from enum import Enum
class Sides(str, Enum):
    SPAM = "Spam"
    EGGS = "eggs"
    ...

preferred_side = Sides.EGGS
match entree[-1]:
    case == Sides.SPAM:  # Compares entree[-1] == Sides.SPAM.
        response = "Have you got anything without Spam?"
    case == preferred_side:  # Compares entree[-1] == preferred_side
        response = f"Oh, I love {preferred_side}!"
    case as side:  # Assigns side = entree[-1].
        response = f"Well, could I have their Spam instead of the {side} then?"

wildcard_pattern: "__"

MatchAlways

match sequence:
    case [__]:               # any sequence with a single element
        return True
    case [start, *__, end]:  # a sequence with at least two elements
        return start == end
    case __:                 # anything
        return False

group_pattern: '(' open_pattern ')'

structural_constraint:
    | sequence_constraint
    | mapping_constraint
    | attrs_constraint
    | class_constraint

sequence_constraint: '[' [sequence_constraint_elements] ']'
sequence_constraint_elements: ','.sequence_constraint_element+ ','?
sequence_constraint_element:
    | star_pattern
    | simple_pattern
    | pattern_as_clause
star_pattern: '*' (pattern_as_clause | wildcard_pattern)

simple_pattern: # Subnode where "as" and "or" patterns must be parenthesised
    | closed_pattern
    | value_constraint

pattern_as_clause: 'as' pattern_capture_target

MatchSequence(pattern* patterns)

MatchRestOfSequence(identifier? target)

mapping_constraint: '{' [mapping_constraint_elements] '}'
mapping_constraint_elements: ','.key_value_constraint+ ','?
key_value_constraint:
    | closed_expr pattern_as_clause
    | closed_expr ':' simple_pattern
    | double_star_capture
double_star_capture: '**' pattern_as_clause

MatchMapping(expr* keys, pattern* patterns)

attrs_constraint:
    | name_or_attr '{' [attrs_constraint_elements] '}'
attrs_constraint_elements: ','.attr_value_pattern+ ','?
attr_value_pattern:
    | '.' NAME pattern_as_clause
    | '.' NAME value_constraint
    | '.' NAME ':' simple_pattern
    | '.' NAME

MatchAttrs(expr cls, identifier* attrs, pattern* patterns)

class_constraint:
    | name_or_attr '(' ')'
    | name_or_attr '(' positional_patterns ','? ')'
    | name_or_attr '(' class_constraint_attrs ')'
    | name_or_attr '(' positional_patterns ',' class_constraint_attrs] ')'
positional_patterns: ','.positional_pattern+
positional_pattern:
    | simple_pattern
    | pattern_as_clause
class_constraint_attrs:
    | '**' '{' [attrs_constraint_elements] '}'

MatchClass(expr cls, pattern* patterns, identifier* extra_attrs, pattern* extra_patterns)

在匹配模式中要求显式限定简单名称

此 PEP 的第一个迭代版本接受了PEP 634的基本前提，即可迭代解包语法将为定义模式匹配的新语法提供良好的基础。

然而，在审查过程中，突出了两个主要问题和一个次要的歧义问题，这些问题直接源于该核心假设

• 最成问题的是，当默认情况下将简单名称绑定扩展到PEP 634提出的类模式语法时，ATTR=TARGET_NAME构造在不使用as关键字的情况下向右绑定，并使用正常的赋值到左侧符号(=)来实现！
• 当默认情况下将简单名称绑定扩展到PEP 634提出的映射模式语法时，KEY: TARGET_NAME构造在不使用as关键字的情况下向右绑定
• 将PEP 634捕获模式与 AS 模式(TARGET_NAME_1 as TARGET_NAME_2)一起使用会导致奇怪的“同时绑定到左侧和右侧”的行为

此 PEP 的第三次修订通过放弃与可迭代解包语法的对齐来解决此问题，而是要求所有对裸简单名称的使用（除了变量查找之外）都必须由前面的符号或关键字限定

• as NAME：局部变量绑定
• .NAME：属性查找
• == NAME：变量查找
• is NAME：变量查找
• 任何其他用法：变量查找

这种方法的主要好处是它使模式中简单名称的解释成为一项本地活动：前导as表示名称绑定，前导.表示属性查找，其他任何内容都是变量查找（无论我们是在读取子模式还是子表达式）。

使用此 PEP 中现在提出的语法，上面确定的问题案例不再读起来很糟糕

• .ATTR as TARGET_NAME 比ATTR=TARGET_NAME更明显地表示绑定
• KEY as TARGET_NAME 比KEY: TARGET_NAME更明显地表示绑定
• (as TARGET_NAME_1) as TARGET_NAME_2 比TARGET_NAME_1 as TARGET_NAME_2更明显地表示两个绑定

抵制猜测的诱惑

PEP 635查看了其他语言中模式匹配的使用方式，并尝试使用这些信息对模式匹配在 Python 中的使用方式做出合理的预测

• 希望将值提取到局部名称中可能比希望与存储在局部名称中的值匹配更常见
• 希望通过相等性进行比较可能比希望通过同一性进行比较更常见
• 即使用户无法在没有阅读文档或有人告诉他们的情况下自己弄清楚，他们也可能至少能够记住裸名称绑定值和属性引用查找值

需要明确的是，我认为这些预测实际上是合理的。但是，我认为我们也不需要事先猜测这一点：我认为我们可以从一个更明确的语法开始，该语法要求用户使用前缀标记（as、==或is）来陈述他们的意图，然后根据模式匹配在 Python 中的实际使用情况在几年后重新评估情况。

在那时，我们将能够在至少以下选项中进行选择

• 确定显式语法足够简洁，并且不更改任何内容
• 为None、...、True和False中的一个或多个添加推断的身份约束
• 为其他文字（可能包括复杂文字）添加推断的相等性约束
• 为属性查找添加推断的相等性约束
• 为裸名称添加推断的相等性约束或推断的捕获模式

所有这些想法都可以根据其自身的优点单独考虑，而不是成为首先引入模式匹配的潜在障碍。

如果最终引入了任何这些语法快捷方式，它们也易于根据底层更显式语法进行解释（前导as、==或is将仅由解析器推断，而无需用户显式提供）。在实现级别，只需要更改解析器，因为可以重用现有的 AST 节点。

与局部变量中属性查找缓存的交互

此 PEP 和PEP 634之间的一个主要变化是使用== EXPR进行相等性约束查找，而不是只提供NAME.ATTR。最初的动机是为了避免与常规赋值目标的语义冲突，其中NAME.ATTR已在赋值语句中用于设置属性，因此，如果NAME.ATTR是符号值匹配的唯一语法，那么我们就会先发制人地排除将来任何尝试使用现有赋值语句语法对单个模式进行匹配的尝试。目前的动机更多地是关于普遍希望避免猜测用户的意图，而是要求他们在语法中明确地陈述意图。

但是，即使在匹配语句本身中，用于值模式的name.attr语法也与局部变量赋值存在不良的交互，其中对于任何其他 Python 语句在语义上为中性的常规重构在应用于PEP 634样式的匹配语句时会引入重大的语义更改。

考虑以下代码

while value < self.limit:
    ... # Some code that adjusts "value"

属性查找可以安全地从循环中提取出来，并且只执行一次

_limit = self.limit:
while value < _limit:
    ... # Some code that adjusts "value"

使用此 PEP 中基于标记前缀的语法提案，值约束将同样容忍将匹配模式重构为使用局部变量而不是属性查找，以下两个语句在功能上是等效的

match expr:
    case {"key": == self.target}:
        ... # Handle the case where 'expr["key"] == self.target'
    case __:
        ... # Handle the non-matching case

_target = self.target
match expr:
    case {"key": == _target}:
        ... # Handle the case where 'expr["key"] == self.target'
    case __:
        ... # Handle the non-matching case

相反，当使用PEP 634省略标记前缀的值和捕获模式语法时，以下两个语句根本不会等效

# PEP 634's value pattern syntax
match expr:
    case {"key": self.target}:
        ... # Handle the case where 'expr["key"] == self.target'
    case _:
        ... # Handle the non-matching case

# PEP 634's capture pattern syntax
_target = self.target
match expr:
    case {"key": _target}:
        ... # Matches any mapping with "key", binding its value to _target
    case _:
        ... # Handle the non-matching case

此 PEP 确保在采用这种简单的重构风格时保留原始语义：使用== name强制将结果解释为值约束，使用as name进行名称绑定。

PEP 634关于仅提供简写语法，不提供显式前缀形式的提案意味着提供的首要答案是“好吧，别那样做，只对比命名空间中的属性，不要对比简单名称”。

PEP 622 的海象运算符语法存在另一个奇怪的交互行为，即它可能不会绑定与 case 子句主体中完全相同的海象运算符表达式相同的对象，但PEP 634 通过将海象运算符模式替换为 AS 模式修复了这种差异（其中，绑定到 RHS 上名称的值可能与 LHS 返回的值不相同，这是所有使用“as”关键字的标准特性）。

使用现有的比较运算符作为值约束前缀

如果接受专用值约束前缀的好处，那么下一个问题就是询问该前缀究竟应该是什么。

本 PEP 最初发布的版本提议使用之前未使用的 ? 符号作为等式约束的前缀，以及 ?is 作为同一性约束的前缀。在审查 PEP 时，Steven D’Aprano 提出了一项有说服力的反建议 [5]，建议使用现有的比较运算符（== 和 is）代替。

在 PEP 的初始迭代中，有一些关于使用 == 作为前缀的担忧，这使得它没有被选为前缀

• 对于常见用例，它甚至比 ? 更加视觉上嘈杂，因为许多接受过 PEP 8 训练的美学意识的人会想要在它和后面的表达式之间加上一个空格，有效地将其变成一个 3 个字符的前缀而不是 1 个字符
• 在映射模式中使用时，需要在 : 键/值分隔符和 == 前缀之间留一个空格，否则标记器将错误地将其拆分（得到 := 和 = 而不是 : 和 ==）
• 在 OR 模式中使用时，需要在 | 模式分隔符和 == 前缀之间留一个空格，否则标记器将错误地将其拆分（得到 |= 和 = 而不是 | 和 ==）
• 如果在 PEP 634 样式的类模式中使用，需要在 = 关键字分隔符和 == 前缀之间留一个空格，否则标记器将错误地将其拆分（得到 == 和 = 而不是 = 和 ==）

Steven 提出的解决这种冗长问题的方案不是引入一个全新的符号，而是保留在语法上明确的情况下省略前缀标记符的能力。

虽然在提案的第二次修订中接受了省略前缀标记符的想法，但在第三次修订中由于模糊性问题而再次放弃了。取而代之的是，以下几点适用

• 对于类模式，其他语法更改允许将等式约束写成 .ATTR == EXPR，并将同一性约束写成 .ATTR is EXPR，这两种写法都非常易于阅读
• 对于映射模式，额外的语法噪声只是被容忍了（至少目前是这样）
• 对于 OR 模式，额外的语法噪声只是被容忍了（至少目前是这样）。但是，成员资格约束 可能会为减少将 OR 模式与等式约束结合的需要提供未来的途径（相反，要检查的值将被收集为集合、列表或元组）。

鉴于这种观点，PEP 635 反对将 ? 作为模式匹配语法的一部分的论点也适用于本提案，因此 PEP 进行了相应修订。

使用__作为通配符模式标记

PEP 635 有力地论证了引入 ? *仅* 作为通配符模式标记符是一个坏主意。由于值约束的语法已更改为使用现有的比较运算符而不是 ? 和 ?is，因此该论点也适用于本 PEP。

但是，正如 Thomas Wouters 在 [6] 中指出的那样，PEP 634 选择 _ 仍然存在问题，因为它可能意味着匹配模式将与 Python 的所有其他部分存在*永久*差异 - 在软件国际化和交互式提示符中使用 _ 意味着实际上没有可行的途径将其用作通用“跳过绑定”标记符。

__ 是从 Stack Overflow 答案 [7]（最初由本 PEP 的作者发布）中提取的另一种“此值不需要”标记符，该答案讨论了现有 Python 代码中 _ 的各种含义。

本 PEP 还提议采用一种实现技术，该技术将 __ 的相关特殊情况的范围限制在解析器：定义一个新的 AST 节点类型（MatchAlways）专门用于通配符标记符，而不是将其作为 Name 节点传递到 AST。

在解析器中，__ 仍然表示在匹配模式中的常规名称或通配符标记符，具体取决于您在解析树中的位置，但在编译器的其余部分，Name("__") 仍然是正常的变量名，而 MatchAlways() 在匹配模式中始终是通配符标记符。

与 _ 不同，__ 没有其他用例，这意味着存在一条可行的途径，可以通过使 __ 在 Python 中的任何地方都表示“跳过此名称绑定”来恢复与语言其余部分的标识符处理一致性

• 在解释器本身中，弃用加载名为 __ 的变量。这将使读取 __ 发出弃用警告，而写入它最初将保持不变。为了避免减慢所有名称加载的速度，这可以通过编译器为弃用的名称发出额外的代码来处理，而不是在标准名称加载操作码中使用运行时检查。
• 在适当数量的版本发布后，更改解析器以对所有用作赋值目标的 __ 的用法发出新的 SkippedBinding AST 节点，并相应地更新编译器的其余部分
• 考虑使 __ 成为真正的硬关键字而不是软关键字

这条弃用路径无法用于 _，因为解释器无法区分在名义上用作“不关心”标记符时尝试读回 _，以及合法地将 _ 作为 i18n 文本翻译函数或作为交互式提示符中的最后一个语句结果读取。

以双下划线开头的名称也已被保留供语言使用，无论是编译时常量（即 __debug__）、特殊方法还是类属性名称混淆，因此在此处使用 __ 将与这种现有方法保持一致。

在抽象语法树中显式表示模式

PEP 634 没有明确讨论如何在抽象语法树中表示匹配语句，而是将此细节留待作为实现的一部分进行定义。

因此，虽然 PEP 634 的参考实现绝对有效（并构成本 PEP 参考实现的基础），但它确实包含一个重大的设计缺陷：尽管 PEP 635 中的注释指出模式应被视为与表达式不同，但参考实现继续在 AST 中将它们表示为表达式节点。

结果是一个根本不抽象的 AST：应该以完全不同的方式编译的节点（因为它们是模式而不是表达式）以相同的方式表示，并且实现语言的类型系统（例如 CPython 的 C）无法提供任何帮助来跟踪哪些子节点应该是普通表达式，哪些应该是子模式。

本 PEP 并没有继续使用这种方法，而是定义了 AST 中一个新的显式“模式”节点，这使得可以在 AST 本身中明确定义模式及其允许的子节点，使实现新功能的代码更清晰，并允许 C 编译器在代码生成器处理模式还是表达式时提供更多帮助。

这种实现方法的更改实际上与本 PEP 中提出的表面语法更改是正交的，因此即使 PEP 的其余部分被拒绝，它仍然可以被采用。

对序列模式的更改

本 PEP 对相对于 PEP 634 的序列模式做了一个值得注意的更改

• 仅支持序列模式的方括号形式。不支持打开（无分隔符）或元组样式（括号作为分隔符）的序列模式。

相对于PEP 634，序列模式也受到更改的重大影响，该更改要求显式限定捕获模式和值约束，这意味着case [a, b, c]:必须改为写成case [as a, as b, as c]:，而case [0, 1]:必须改为写成case [== 0, == 1]:。

由于序列模式的语法不再直接从可迭代解包的语法派生而来，因此不再有意义地保留最初语法提案中纯粹为了与可迭代解包保持一致而包含的语法灵活性。

允许开放式和元组风格的序列模式并没有提高表达能力，只会增加意图的歧义（尤其是相对于组模式），并鼓励读者将模式匹配语法视为与赋值目标语法内在地相关联（PEP 634 的作者多次声明这不是读者希望走的路，而本 PEP 的作者现在也同意这种观点，尽管最初不同意）。

对映射模式的更改

本 PEP 对映射模式相对于PEP 634 做了两个显著的更改。

• 值捕获写成KEY as NAME，而不是KEY: NAME
• 允许更广泛的键：任何“封闭表达式”，而不仅仅是字面量和属性引用。

如上所述，第一个更改是确保所有使用目标名称绑定到子表达式或模式右侧的操作都使用as关键字。

第二个更改主要是通过重用现有的表达式处理机制来简化解析器和代码生成器代码。对封闭表达式的限制旨在帮助减少关于键表达式在哪里结束以及匹配模式在哪里开始的歧义。这主要允许PEP 634 允许的超集，除了复杂字面量必须用括号括起来（至少目前是这样）。

将PEP 635 的映射模式示例改编为本 PEP 中提出的语法。

match json_pet:
    case {"type": == "cat", "name" as name, "pattern" as pattern}:
        return Cat(name, pattern)
    case {"type": == "dog", "name" as name, "breed" as breed}:
        return Dog(name, breed)
    case __:
        raise ValueError("Not a suitable pet")

def change_red_to_blue(json_obj):
    match json_obj:
        case { 'color': (== 'red' | == '#FF0000') }:
            json_obj['color'] = 'blue'
        case { 'children' as children }:
            for child in children:
                change_red_to_blue(child)

作为参考，等效的PEP 634 语法。

match json_pet:
    case {"type": "cat", "name": name, "pattern": pattern}:
        return Cat(name, pattern)
    case {"type": "dog", "name": name, "breed": breed}:
        return Dog(name, breed)
    case _:
        raise ValueError("Not a suitable pet")

def change_red_to_blue(json_obj):
    match json_obj:
        case { 'color': ('red' | '#FF0000') }:
            json_obj['color'] = 'blue'
        case { 'children': children }:
            for child in children:
                change_red_to_blue(child)

对类模式的更改

本 PEP 对类模式相对于PEP 634 做了几个显著的更改。

• 放弃了与类实例化的语法对齐，因为它具有误导性和无帮助性。相反，引入了一种新的专用语法来检查其他属性，该语法借鉴了映射模式而不是类实例化。
• 引入了一种新的专用语法用于简单的鸭子类型检查，适用于任何类。
• 各种内置类型和标准库类型的特殊情况得到了补充，通过通用检查__match_args__属性是否存在且值为None。

如上所述，第一个更改有两个目的。

• 它是确保所有使用目标名称绑定到子表达式或模式右侧的操作都使用as关键字的一部分。使用=分配到右侧尤其成问题。
• 它是确保模式中所有简单名称的使用都具有指示其目的的前缀（在本例中，前导.指示属性查找）的一部分。

与类实例化的语法对齐也被认为总体上没有帮助，因为类模式是关于将模式与属性进行匹配，而类实例化是关于将调用参数与类构造函数中的参数进行匹配，这可能与生成的实例属性没有太大关系。

第二个更改旨在使在 Python 中已经很常见的“鸭子类型”样式检查更容易使用模式匹配。

然后，这些模式的具体语法提案源于将实例视为属性名称到值的映射，并将属性查找语法（.ATTR）与映射模式语法{KEY: PATTERN}结合起来，得到cls{.ATTR: PATTERN}。

允许cls{.ATTR}与cls{.ATTR: __}具有相同含义是考虑到前导.足以使名称使用变得明确（它显然是属性引用，而与映射模式中的变量键进行匹配则可能存在歧义）。

最终的更改只是通过使其成为类在未定义__match_args__时获得的默认行为来补充PEP 634 参考实现中仅限于 CPython 内部的一个检查（保留了PEP 634 中命名的内置类型和标准库类型的优化快速路径）。

改编PEP 635 中链接的类匹配示例表明，对于纯位置类匹配，主要影响来自值约束和名称绑定的更改，而不是来自类匹配的更改。

match expr:
    case BinaryOp(== '+', as left, as right):
        return eval_expr(left) + eval_expr(right)
    case BinaryOp(== '-', as left, as right):
        return eval_expr(left) - eval_expr(right)
    case BinaryOp(== '*', as left, as right):
        return eval_expr(left) * eval_expr(right)
    case BinaryOp(== '/', as left, as right):
        return eval_expr(left) / eval_expr(right)
    case UnaryOp(== '+', as arg):
        return eval_expr(arg)
    case UnaryOp(== '-', as arg):
        return -eval_expr(arg)
    case VarExpr(as name):
        raise ValueError(f"Unknown value of: {name}")
    case float() | int():
        return expr
    case __:
        raise ValueError(f"Invalid expression value: {repr(expr)}")

作为参考，等效的PEP 634 语法。

match expr:
    case BinaryOp('+', left, right):
        return eval_expr(left) + eval_expr(right)
    case BinaryOp('-', left, right):
        return eval_expr(left) - eval_expr(right)
    case BinaryOp('*', left, right):
        return eval_expr(left) * eval_expr(right)
    case BinaryOp('/', left, right):
        return eval_expr(left) / eval_expr(right)
    case UnaryOp('+', arg):
        return eval_expr(arg)
    case UnaryOp('-', arg):
        return -eval_expr(arg)
    case VarExpr(name):
        raise ValueError(f"Unknown value of: {name}")
    case float() | int():
        return expr
    case _:
        raise ValueError(f"Invalid expression value: {repr(expr)}")

类模式语法本身的更改在检查命名属性并提取其值而不依赖于__match_args__时更相关。

match expr:
    case object{.host as host, .port as port}:
        pass
    case object{.host as host}:
        pass

将其与PEP 634 等效项进行比较，在该等效项中，不清楚哪些名称指的是匹配主题的属性，哪些名称指的是局部变量。

match expr:
    case object(host=host, port=port):
        pass
    case object(host=host):
        pass

在这种特定情况下，歧义无关紧要（因为属性和变量名称相同），但在一般情况下，知道哪个是哪个对于正确推理正在读取的代码至关重要。

推断值约束

如上所述，本 PEP 并不排除将来添加推断的相等和同一性约束的可能性。

对于字面量，这些可能特别有价值，因为许多具有不言而喻含义的“魔术”字符串和数字很可能直接写入匹配模式，而不是存储在命名变量中。（例如None之类的常量，或者0和1之类的明显特殊数字，或者其内容与任何变量名称一样具有描述性的字符串，而不是对像739452这样的不透明数字进行神秘的检查）。

使某些必需的括号可选

PEP 目前严重偏向于在出现潜在歧义时要求使用括号。

但是，在许多情况下，它至少可以说走得太远了，主要涉及具有显式模式的 AS 模式。

在任何需要封闭模式的位置，AS 模式可能以双括号开头，因为嵌套模式也需要是封闭模式：((OPEN PTRN) as NAME)

由于子模式需要是封闭的，因此在许多这些情况下（例如序列模式子模式），直接接受CLOSED_PTRN as NAME应该是合理的。

对这一点的进一步考虑已被推迟，因为使必需的括号可选是向后兼容的更改，因此以后可以根据具体情况放宽限制。

接受复杂字面量作为封闭表达式

PEP 634 的参考实现在解析器和编译器的其余部分中包含大量二元运算符的特殊情况，以便接受复杂字面量而不接受对字面值的任意二元数值运算。

理想情况下，这个问题将在解析器层解决，解析器直接发出一个用复数预填充的 Constant AST 节点。如果情况如此，那么可以通过类似于任何其他字面量的机制来接受复杂字面量。

然而，这不是处理复杂字面量的方式。相反，它们作为常规BinOp节点传递到 AST，然后 AST 上的常量折叠传递将它们解析为具有复数值的Constant节点。

为了让解析器直接解析复杂字面量，编译器需要能够告诉标记生成器为虚数生成不同的标记类型（例如INUMBER），然后解析器就可以分别处理NUMBER + INUMBER和NUMBER - INUMBER，而不是其他二元运算。

或者，可以定义一个新的ComplexNumber AST 节点类型，这将允许解析器通知后续的编译器阶段特定节点应该专门是一个复杂字面量，而不是一个任意二元运算。然后解析器可以接受NUMBER + NUMBER和NUMBER - NUMBER用于该节点，同时让ComplexNumber的 AST 验证确保字面量的实部和虚部分别是实数和虚数，如预期的那样。

目前，本 PEP 已推迟处理此问题，而是只要求将复杂字面量括在括号中才能用于值约束和作为映射模式键。

允许在匹配模式中使用否定约束

使用本 PEP 中提出的语法，不允许写!= expr或is not expr作为匹配模式。

这两种形式都具有明确的潜在解释，即作为否定相等约束（即x != expr）和否定同一性约束（即x is not expr）。

然而，目前尚不清楚这两种形式是否会频繁出现到足以证明专用语法的合理性，因此可能的扩展已被推迟，等待社区进一步积累使用 match 语句的经验。

允许在匹配模式中使用成员资格检查

用于相等性和同一性约束的语法可以很容易地扩展到成员资格检查：in container。

本 PEP 和PEP 634中提出的方案的一个缺点是，在同一个 case 中检查多个值的方式与 Python 中现有的任何容器成员资格检查都不一样。

# PEP 634's literal patterns
match value:
    case 0 | 1 | 2 | 3:
        ...

# This PEP's equality constraints
match value:
    case == 0 | == 1 | == 2 | == 3:
        ...

根据本 PEP 允许推断相等性约束只会使其看起来像PEP 634中的示例，它仍然不像等效的 if 语句头 (if value in {0, 1, 2, 3}:)。

成员资格约束将提供一种更明确但仍然简洁的方式来检查匹配主体是否存在于容器中，并且它看起来与普通的包含检查相同。

match value:
    case in {0, 1, 2, 3}:
        ...
    case in {one, two, three, four}:
        ...
    case in range(4): # It would accept any container, not just literal sets
        ...

此功能还可以轻松扩展以允许所有类型的 case 子句，而无需任何进一步的语法更新，只需在自定义类定义上适当地定义 __contains__ 即可。

然而，虽然这似乎是一个有用的扩展，并且是解决本 PEP 在将多个相等性检查组合成 OR 模式时的冗长问题的好方法，但它对于使 match 语句成为对语言的宝贵补充并不是必不可少的，因此将其推迟到单独的提案中似乎更合适，而不是将其包含在此处。

为实例属性约束推断默认类型

实例属性约束的专用语法意味着可以从 object{.ATTR} 中省略 object 以得到 {.ATTR}，而不会引入任何语法歧义（如果没有给出类，则会隐含 object，就像在类定义中隐含基类列表一样）。

但是，目前尚不清楚节省六个字符是否值得使映射模式与实例属性模式在视觉上更难以区分，因此允许这样做已被推迟，作为将来可能考虑的主题。

避免序列模式中的特殊情况

本 PEP 和PEP 634中的序列模式目前将 str、bytes 和 bytearray 特殊情况处理为永远不匹配序列模式。

如果我们要为这些类型定义一个新的 collections.abc.AtomicSequence 抽象基类，则可以删除此特殊情况处理，其中它们在概念上是一个项目，但仍然实现序列协议以允许随机访问其组成部分。

从实例检索多个属性的表达式语法

实例属性模式语法的设计使得它可以作为从对象中用单个表达式检索多个属性的通用语法的基础。

host, port = obj{.host, .port}

类似于切片语法仅允许在括号下标内使用，用于命名属性的 .attr 语法仅允许在大括号下标内使用。

模式匹配要变得有用并不需要这个想法，所以它不是本 PEP 的一部分。但是，它被提到了，作为一个可能的途径，使模式匹配感觉更融入语言的其余部分，而不是永远存在于它自己的完全分离的世界中。

从实例检索多个属性的表达式语法

如果大括号下标语法被接受用于实例属性模式匹配，然后随后扩展为提供对多个属性的通用提取，那么它可以进一步扩展以允许根据用于映射模式匹配的语法从容器中检索多个项目。

host, port = obj{"host", "port"}
first, last = obj{0, -1}

同样，模式匹配要变得有用并不需要这个想法，所以它不是本 PEP 的一部分。但是，与检索多个属性一样，它被包含在内，作为提议的模式匹配语法激发使对象分解更容易的想法的一个示例。

限制值约束和映射模式键中允许的表达式

虽然从技术上完全可以将值约束和映射模式键中允许的表达式类型限制为仅属性查找和常量文字（就像PEP 634那样），但这样做没有任何明显的运行时价值，因此本 PEP 建议允许任何类型的基本表达式（基本表达式是语法中现有的节点类型，包括文字、名称、属性查找、函数调用、容器下标、带括号的组等），以及基本表达式上的高优先级一元运算符 (+、-、~)。

虽然PEP 635确实多次强调字面量模式和值模式不是完整的表达式，但它从未阐明从该限制中获得的具体好处（只是一个理论上的吸引力，认为将静态检查与动态检查分开是有用的，即使编译器本身更宽松，代码风格工具也可以仍然执行此操作）。

我们上次实施此类限制是在装饰器表达式中，其主要结果是用户不得不忍受多年的笨拙的语法变通方法（例如，将任意表达式嵌套在仅返回其参数的函数调用中），以表达他们想要的行为，然后语言定义最终更新为允许任意表达式并让用户自己决定可读性。

在PEP 634中，与装饰器表达式的情况类似的是，在值模式中技术上支持任意表达式，它们只需要笨拙的变通方法，其中需要在 match 语句之前放置辅助类中指定所有要匹配的值。

# Allowing arbitrary match targets with PEP 634's value pattern syntax
class mt:
    value = func()
match expr:
    case (_, mt.value):
        ... # Handle the case where 'expr[1] == func()'

或者需要将其写成捕获模式和保护表达式的组合。

# Allowing arbitrary match targets with PEP 634's guard expressions
match expr:
    case (_, _matched) if _matched == func():
        ... # Handle the case where 'expr[1] == func()'

本 PEP 建议跳过任何此类变通方法的要求，而是从一开始就支持任意值约束。

match expr:
    case (__, == func()):
        ... # Handle the case where 'expr == func()'

是否实际编写这种代码是一个好主意将是风格指南和代码 linter 的主题，而不是语言编译器。

特别是，如果静态分析器无法遵循某些类型的动态检查，那么它们可以在分析时限制允许的表达式，而不是编译器在编译时限制它们。

还有一些表达式几乎肯定会导致毫无意义的结果（例如 yield、yield from、await），因为模式缓存规则，约束表达式实际评估的次数将取决于实现。即使在这里，PEP 也持有一种观点，即如果用户确实想要，则允许他们编写无意义的内容。

除了最近更新的装饰器表达式之外，Python 的正式语法提供完全表达自由但在实践中几乎从未使用过的另一种情况是在 except 子句中：要匹配的异常几乎总是采用简单名称、带点名称或这些名称的元组的形式，但语言语法在这一点上允许任意表达式。这表明可以信任 Python 的用户群能够找到可读的方式来使用宽松的语言特性，通过避免编写难以阅读的结构，即使编译器允许它们。

这种宽松性带来了一个真正的具体实现方面的好处：编译器中数十行 match 语句特定代码被对用于编译表达式的现有代码的简单调用所取代（包括在 AST 验证传递、AST 优化传递、符号表分析传递和代码生成传递中）。这种实现优势不仅会惠及 CPython，还会惠及所有其他希望添加 match 语句支持的 Python 实现。

要求对映射模式键使用约束前缀标记

该提案的初始（未发表的）草案建议要求映射模式键为值约束，就像PEP 634要求它们是有效的字面量或值模式一样。

import constants

match config:
    case {== "route": route}:
        process_route(route)
    case {== constants.DEFAULT_PORT: sub_config, **rest}:
        process_config(sub_config, rest)

但是，额外的字符在语法上很嘈杂，并且与它在值约束中的用法不同（在其中它将它们与非模式表达式区分开来），该前缀在此处没有提供任何映射模式键中表达式的定位未已传达的其他信息。

因此，该提案已简化为从映射模式键中省略标记前缀。

此省略也与容器可能在其查找过程中包含同一性和相等性检查这一事实相一致——它们并不完全依赖于相等性检查，因为使用相等性约束前缀会错误地暗示这一点。

允许省略映射值约束的键/值分隔符

实例属性模式允许在编写属性值约束（如 case object{.attr == expr}）时省略 : 分隔符。

考虑为映射值约束提供类似的简写，但允许它会允许彻底令人困惑的结构，例如 case {0 == 0}:，其中编译器知道这是键 0，其值约束为 == 0，但人类读者会看到同义比较运算 0 == 0。包含键/值分隔符后，对于人类读者来说，意图更加明显：case {0: == 0}: