match 语义

不同 case 子句的模式可能会重叠，因为多个 case 子句会匹配给定的主题。先匹配规则确保对给定主题的 case 子句选择是明确的。此外，case 子句可以具有越来越通用的模式，以匹配更广泛的主题集。然后，先匹配规则确保可以选择最精确的模式（尽管程序员有责任正确排序 case 子句）。

在静态类型语言中，match 语句将被编译成决策树以快速有效地选择匹配模式。但是，这将要求所有模式都纯粹是声明性的和静态的，这与 Python 已建立的动态语义相冲突。因此，建议的语义代表了一条融合两方面优点的路径：模式按严格的顺序尝试，以便每个 case 子句都构成一个实际语句。同时，我们允许解释器缓存关于主题的任何信息或更改尝试子模式的顺序。换句话说：如果解释器发现主题不是类C的实例，它可以直接跳过再次测试此类的 case 子句，而无需执行重复的实例检查。如果一个守卫规定变量x必须为正（例如if x > 0），则解释器可能会在绑定x之后以及考虑任何其他子模式之前直接检查这一点。

绑定和作用域。在许多模式匹配实现中，每个 case 子句都会建立一个单独的作用域。然后，由模式绑定的变量仅在相应的 case 代码块内可见。但是，在 Python 中，这没有意义。建立单独的作用域基本上意味着每个 case 子句都是一个单独的函数，无法直接访问周围作用域中的变量（无需诉诸nonlocal）。此外，case 子句将无法再通过标准语句（如return或break）影响任何周围的控制流。因此，这种严格的作用域会导致不直观和令人惊讶的行为。

这直接导致任何变量绑定都比相应的 case 或 match 语句存活时间长。即使仅部分匹配主题的模式也可能绑定局部变量（实际上，这对于守卫正常工作是必要的）。但是，这些变量绑定的语义与现有的 Python 结构（如 for 循环和 with 语句）一致。

守卫

某些约束无法仅通过模式充分表达。例如，“小于”或“大于”关系违反了模式通常的“等于”语义。此外，不同的子模式是独立的，不能相互引用。守卫的添加解决了这些限制：守卫是附加到模式的任意表达式，并且必须计算为“真值”才能使模式成功。

例如，case [x, y] if x < y:使用守卫（if x < y）来表达两个否则不相交的捕获模式x和y之间的“小于”关系。

从概念上讲，模式以声明式风格描述主题的结构约束，理想情况下没有任何副作用。特别是，请记住，模式与表达式明显不同，遵循不同的目标和语义。然后，守卫以高度受控的方式使用任意表达式（可能具有副作用）增强 case 代码块。将整体功能拆分为静态结构部分和动态评估部分，不仅有助于可读性，还可以为编译器优化带来巨大的潜力。为了保持这种清晰的分离，仅在 case 子句级别支持守卫，而不支持单个模式。

示例使用守卫

def sort(seq):
    match seq:
        case [] | [_]:
            return seq
        case [x, y] if x <= y:
            return seq
        case [x, y]:
            return [y, x]
        case [x, y, z] if x <= y <= z:
            return seq
        case [x, y, z] if x >= y >= z:
            return [z, y, x]
        case [p, *rest]:
            a = sort([x for x in rest if x <= p])
            b = sort([x for x in rest if p < x])
            return a + [p] + b

AS 模式

模式分为两类：大多数模式施加主题需要满足的（结构）约束，而捕获模式将主题绑定到名称，而不管主题的结构或实际值如何。因此，模式可以表达约束或绑定值，但不能两者兼而有之。AS 模式填补了这一空白，因为它允许用户指定通用模式以及在变量中捕获主题。

AS 模式的一些典型用例包括 OR 和 Class 模式以及绑定名称，例如case BinOp('+'|'-' as op, ...):或case [int() as first, int() as second]:。后者可以理解为主题必须满足两个不同的模式：[first, second]以及[int(), int()]。因此，AS 模式可以被视为“and”模式的特例（有关“and”模式的其他讨论，请参见下面的 OR 模式）。

在早期版本中，AS 模式被设计为“海豹模式”，写成case [first:=int(), second:=int()]。但是，使用as比:=提供了一些优势

• 海象运算符 := 用于捕获右侧表达式的结果，而 as 通常表示某种形式的“处理”，例如 import foo as bar 或 except E as err:。实际上，模式 P as x 不会将模式 P 赋值给 x，而是将成功匹配 P 的主体赋值给 x。
• as 允许数据从左到右更一致地流动（类模式中的属性也遵循从左到右的数据流）。
• 海象运算符看起来非常类似于类模式中匹配属性的语法，可能会导致一些混淆。

示例 使用 AS 模式

def simplify_expr(tokens):
    match tokens:
        case [('('|'[') as l, *expr, (')'|']') as r] if (l+r) in ('()', '[]'):
            return simplify_expr(expr)
        case [0, ('+'|'-') as op, right]:
            return UnaryOp(op, right)
        case [(int() | float() as left) | Num(left), '+', (int() | float() as right) | Num(right)]:
            return Num(left + right)
        case [(int() | float()) as value]:
            return Num(value)

OR 模式

OR 模式允许你将“结构上等价”的备选方案组合成一个新的模式，即多个模式可以共享一个共同的处理程序。如果 OR 模式的任何子模式与主体匹配，则整个 OR 模式都成功。

静态类型语言禁止在 OR 模式内绑定名称（捕获模式），因为变量类型的潜在冲突。作为动态类型语言，Python 在这里可以不那么严格，允许在 OR 模式内使用捕获模式。但是，每个子模式必须绑定相同的变量集，以免留下可能未定义的名称。对于两个备选方案 P | Q，这意味着如果 P 绑定变量 u 和 v，则 Q 必须精确绑定相同的变量 u 和 v。

关于是否使用竖线符号 | 或 or 关键字来分隔备选方案，曾有一些讨论。OR 模式并不完全符合这两个符号现有的语义和用法。但是，| 是所有支持 OR 模式的编程语言中选择的符号，并且在 Python 中也用于正则表达式中的该功能。它也是形式语法（包括 Python 的语法）中备选方案的传统分隔符。此外，| 不仅用于按位 OR，还用于集合联合和字典合并（PEP 584）。

也考虑了其他备选方案，但这些方案都不允许 OR 模式嵌套在其他模式中。

• 使用逗号:

  case 401, 403, 404:
      print("Some HTTP error")
  

  这看起来太像元组了——我们将不得不找到一种不同的方式来拼写元组，并且该结构必须在类模式的参数列表内使用括号括起来。一般来说，逗号在 Python 中已经有很多不同的含义，我们不应该再添加更多含义。

• 使用堆叠的 case:

  case 401:
  case 403:
  case 404:
      print("Some HTTP error")
  

  这将是 C 中使用其 case 语句的贯穿语义的方式。但是，我们不想误导人们认为 match/case 使用贯穿语义（这是 C 中常见的错误来源）。此外，这将是一种新颖的缩进模式，这可能会使 IDE 等工具更难以支持（它将破坏简单的规则“在以冒号结尾的行后添加一个缩进级别”）。最后，这也将不支持嵌套在其他模式内的 OR 模式。

• 使用“case in”后跟逗号分隔的列表:

  case in 401, 403, 404:
      print("Some HTTP error")
  

  这将不适用于嵌套在其他模式内的 OR 模式，例如

  case Point(0|1, 0|1):
      print("A corner of the unit square")
  

AND 和 NOT 模式

由于此提案定义了 OR 模式（|）来匹配多个备选方案中的一个，为什么不也定义 AND 模式（&）甚至 NOT 模式（!）呢？特别是考虑到其他一些语言（例如 F#）支持 AND 模式。

但是，目前尚不清楚这将有多大用处。匹配字典、对象和序列的语义已经包含了一个隐式的“and”：所有提到的属性和元素都必须存在才能使匹配成功。保护条件也可以支持假设的“and”运算符将用于的许多用例。

使用运算符 ! 作为前缀对匹配模式进行否定，将完全匹配如果模式本身不匹配。例如，!(3 | 4) 将匹配除 3 或 4 之外的任何内容。但是，有来自其他语言的证据表明这很少有用，主要用作双重否定 !! 来控制变量范围并防止变量绑定（这并不适用于 Python）。其他用例最好使用保护条件来表达。

最终，我们决定这将使语法变得更复杂，而不会带来明显的益处。它可以随时稍后添加。

示例 使用 OR 模式

def simplify(expr):
    match expr:
        case ('/', 0, 0):
            return expr
        case ('*'|'/', 0, _):
            return 0
        case ('+'|'-', x, 0) | ('+', 0, x) | ('*', 1, x) | ('*'|'/', x, 1):
            return x
    return expr

字面量模式

字面量模式是一种方便的方式，用于对主体的值施加约束，而不是其类型或结构。它们还允许你使用模式匹配模拟 switch 语句。

通常，主体通过标准相等性与字面量模式进行比较（在 Python 语法中为 x == y）。因此，字面量模式 1.0 和 1 精确匹配同一组对象，即 case 1.0: 和 case 1: 是完全可互换的。原则上，True 也将匹配同一组对象，因为 True == 1 成立。但是，我们认为许多用户会惊讶地发现 case True: 匹配主体 1.0，从而导致一些细微的错误和复杂的解决方法。因此，我们采用了以下规则：三个单例模式 None、False 和 True 通过身份（在 Python 语法中为 x is y）而不是相等性进行匹配。因此，case True: 将仅匹配 True 以及其他任何内容。请注意，case 1: 仍然会匹配 True，因为字面量模式 1 通过相等性而不是身份工作。

早期的想法是在数字上引入层次结构，以便 case 1.0 将匹配整数 1 和浮点数 1.0，而 case 1: 将仅匹配整数 1，最终被放弃，转而采用基于相等性的更简单、更一致的规则。此外，任何额外的检查主体是否为 numbers.Integral 的实例，都会带来很高的运行时成本，从而引入本质上是 Python 中一个新概念的东西。如果需要，可以使用显式语法 case int(1):。

回想一下，字面量模式**不是**表达式，而是直接表示特定值。从实用角度来看，我们希望允许使用负数甚至复数值作为字面量模式，但它们不是原子字面量（只有无符号实数和虚数才是）。例如，-3+4j 在语法上是表单 BinOp(UnaryOp('-', 3), '+', 4j) 的表达式。由于表达式不是模式的一部分，因此我们必须为这些值添加显式的语法支持，而无需诉诸完整的表达式。

另一方面，内插的 f-字符串不是字面量值，尽管它们的外观如此，因此不能用作字面量模式（但是，支持字符串连接）。

字面量模式不仅本身作为模式出现，而且作为映射模式中的键出现。

范围匹配模式。这将允许诸如 1...6 之类的模式。但是，存在许多歧义

• 范围是开、半开还是闭？(即，在上面的例子中 6 是否包含在内？)
• 范围是否匹配单个数字或范围对象？
• 范围匹配通常用于字符范围（'a'…’z'），但这在 Python 中不起作用，因为没有字符数据类型，只有字符串。
• 如果可以预先构建跳转表，则范围匹配通常可以成为一项重要的性能优化，但这在 Python 中通常是不可能的，因为名称可以动态重新绑定。

与其为范围创建特殊情况的语法，不如决定允许自定义模式对象（InRange(0, 6)）会更灵活且更少歧义；但是这些想法暂时被搁置了。

示例 使用字面量模式

def simplify(expr):
    match expr:
        case ('+', 0, x):
            return x
        case ('+' | '-', x, 0):
            return x
        case ('and', True, x):
            return x
        case ('and', False, x):
            return False
        case ('or', False, x):
            return x
        case ('or', True, x):
            return True
        case ('not', ('not', x)):
            return x
    return expr

捕获模式

捕获模式采用名称的形式，该名称接受任何值并将其绑定到一个（局部）变量（除非该名称被声明为 nonlocal 或 global）。从这个意义上说，捕获模式类似于函数定义中的参数（当调用函数时，每个参数都会将相应的参数绑定到函数作用域中的局部变量）。

用于捕获模式的名称不得与同一模式中的其他捕获模式重名。这再次类似于参数，参数也要求每个参数名称在参数列表中唯一。但是，它与可迭代解包赋值不同，在可迭代解包赋值中，允许重复使用变量名作为目标（例如，x, x = 1, 2）。不支持模式中使用(x, x) 的原因在于其解读存在歧义：它可能被视为可迭代解包，其中只有第二个绑定到x 的绑定会被保留。但它也可能被视为表示一个有两个相等元素的元组（这本身也存在一些问题）。如果需要，将来仍然可以引入对重复使用名称的支持。

曾有人提议显式标记捕获模式，从而将其识别为绑定目标。根据这个想法，捕获模式可以写成例如?x、$x 或=x。这种显式捕获标记的目的是让未标记的名称成为值模式（见下文）。然而，这是基于这样一个误解，即模式匹配是switch 语句的扩展，强调基于（序数）值的快速切换。Python 之前确实有人提议过这样的switch 语句（参见PEP 275 和PEP 3103）。另一方面，模式匹配构建了一个可迭代解包的广义概念。从数据结构中提取并绑定值是该概念的核心，也是最常见的用例。因此，显式捕获模式标记会背离所提出的模式匹配语法的目标，并以牺牲核心用例的额外语法杂乱为代价，简化了一个次要的用例。

有人提议根本不需要捕获模式，因为可以通过将 AS 模式与通配符模式结合来获得相同的效果（例如，case _ as x 等价于 case x）。但是，这会显得冗长乏味，特别是考虑到我们预计捕获模式会非常常见。

示例：使用捕获模式

def average(*args):
    match args:
        case [x, y]:           # captures the two elements of a sequence
            return (x + y) / 2
        case [x]:              # captures the only element of a sequence
            return x
        case []:
            return 0
        case a:                # captures the entire sequence
            return sum(a) / len(a)

通配符模式

通配符模式是“捕获”模式的一种特殊情况：它接受任何值，但不将其绑定到变量。此规则背后的理念是支持在模式中重复使用通配符。虽然(x, x) 是错误的，但(_, _) 是合法的。

特别是在较大的（序列）模式中，允许模式专注于具有实际意义的值，同时忽略其他任何内容非常重要。如果没有通配符，则需要“发明”许多局部变量，这些变量会被绑定但从未使用。即使坚持命名约定并使用例如_1, _2, _3 来命名无关的值，这仍然会引入视觉杂乱并可能影响性能（将序列模式(x, y, *z) 与(_, y, *_) 进行比较，其中*z 强制解释器复制一个可能非常长的序列，而第二个版本则简单地编译成类似于y = seq[1] 的代码）。

关于选择下划线_ 作为通配符模式，即使这个名称不进行绑定，已经有很多讨论。但是，下划线已经被大量用作可迭代解包中的“忽略值”标记。由于通配符模式_ 从不绑定，因此下划线的这种用法不会干扰其他用法，例如在 REPL 或gettext 模块内部的用法。

有人提议使用...（即省略号标记）或*（星号）作为通配符。但是，这两个看起来都像是省略了任意数量的项。

case [a, ..., z]: ...
case [a, *, z]: ...

这两个示例看起来都像是匹配两个或更多项的序列，捕获第一个和最后一个值。虽然这可能是最终的“通配符”，但它并没有传达所需的语义。

一个不暗示任意数量项的替代方案是?。这甚至在PEP 640 中独立于模式匹配而被提出。但是，我们认为将? 用作特殊的“赋值”目标可能会比使用_ 对 Python 用户造成更多困惑。它违反了 Python（诚然模糊）的原则，即仅以与它们在常用英语用法或高中数学中使用方式类似的方式使用标点符号，除非这种用法在其他编程语言中非常 完善（例如，使用点进行成员访问）。

问号在这两方面都失败了：它在其他编程语言中的使用是一个“问题”概念的各种用法，这些用法只是隐约地暗示了这个概念。例如，在 shell 通配符中表示“任何字符”，在正则表达式中表示“可能”，在 C 和许多 C 派生语言中表示“条件表达式”，在 Scheme 中表示“谓词函数”，在 Rust 中表示“修改错误处理”，在 TypeScript 中表示“可选参数”和“可选链”（后者含义也已由PEP 505 提议用于 Python）。一个尚未命名的 PEP 提议用它来标记可选类型，例如int?。

编程系统中? 的另一个常见用法是“帮助”，例如在 IPython 和 Jupyter Notebook 以及许多交互式命令行实用程序中。

此外，这会使 Python 处于一个相当独特的位置：下划线作为通配符模式出现在我们能找到的所有 具有模式匹配的编程语言中（包括C#、Elixir、Erlang、F#、Grace、Haskell、Mathematica、OCaml、Ruby、Rust、Scala、Swift 和Thorn）。考虑到许多 Python 用户也使用其他编程语言，在学习 Python 时拥有先前的经验，并且可能在学习 Python 后转向其他语言，我们发现这种完善的标准对于可读性和可学习性非常重要和相关。在我们看来，担心此通配符意味着常规名称受到特殊处理的顾虑不足以引入使 Python 特殊的语法。

Else 块。其模式为单个通配符（即case _:）且没有保护的 case 块接受任何主题，而无需将其绑定到变量或执行任何其他操作。因此，如果支持的话，它在语义上等同于else:。但是，将这样的 else 块添加到 match 语句语法中并不会消除在其他上下文中对通配符模式的需求。另一个反对意见是，else 块将有两个可能的缩进级别：与case 对齐或与match 对齐。作者发现选择哪个缩进级别颇有争议。

示例：使用通配符模式

def is_closed(sequence):
    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

值模式

对于参数值或阐明特定值的含义，使用命名常量是一种良好的编程风格。显然，最好编写case (HttpStatus.OK, body): 而不是case (200, body):，例如。这里出现的主要问题是如何区分捕获模式（变量绑定）和值模式。围绕此问题的总体讨论提出了大量选项，我们无法在这里全部列出。

严格来说，值模式并不是真正必要的，但可以使用保护来实现，即case (status, body) if status == HttpStatus.OK:。尽管如此，值模式的便利性是毋庸置疑且显而易见的。

观察到常量倾向于用大写字母编写或收集在类似枚举的命名空间中，这表明可以根据语法来识别常量。但是，使用大小写作为标记的想法遭到了质疑，因为在核心 Python 中没有类似的先例（尽管在其他语言中很常见）。因此，我们只采用了以下规则：任何带点的名称（即属性访问）都应解释为值模式，例如上面的HttpStatus.OK。这尤其排除了局部变量和当前模块中定义的全局变量充当常量。

有人提议为此目的使用前导点（例如.CONSTANT），但遭到批评，因为人们认为点不是为此目的而设计的足够明显的标记。部分受到其他编程语言中形式的启发，提出了许多不同的标记/符号（例如^CONSTANT、$CONSTANT、==CONSTANT、CONSTANT? 或用反引号括起来单词），尽管没有明显或自然的选项。因此，当前提案将此类“常量”标记的讨论和可能的引入留给未来的 PEP。

基于名称是全局变量（即编译器将全局变量视为常量而不是捕获模式）来区分名称的语义会导致各种问题。模块中全局变量的添加或更改可能会对模式产生意外的副作用。此外，模式匹配无法直接在模块的作用域内使用，因为所有变量都将是全局的，这使得捕获模式变得不可能。

示例：使用值模式

def handle_reply(reply):
    match reply:
        case (HttpStatus.OK, MimeType.TEXT, body):
            process_text(body)
        case (HttpStatus.OK, MimeType.APPL_ZIP, body):
            text = deflate(body)
            process_text(text)
        case (HttpStatus.MOVED_PERMANENTLY, new_URI):
            resend_request(new_URI)
        case (HttpStatus.NOT_FOUND):
            raise ResourceNotFound()

组模式

允许用户显式指定分组在 OR 模式的情况下特别有用。

序列模式

序列模式尽可能遵循已建立的可迭代解包的语法和语义。当然，子模式取代了赋值目标（变量、属性和下标）。此外，序列模式只匹配一组精心挑选的可能的主题，而可迭代解包可以应用于任何可迭代对象。

• 与可迭代解包一样，我们不区分“元组”和“列表”表示法。[a, b, c]、(a, b, c) 和 a, b, c 都是等价的。虽然这意味着我们有一种冗余的表示法，并且专门检查列表或元组需要更多努力（例如 case list([a, b, c])），但我们尽可能地模仿可迭代解包。
• 星号模式将捕获任意长度的子序列，再次反映可迭代解包。任何序列模式中只能存在一个星号项。理论上，像 (*_, 3, *_) 这样的模式可以理解为表示包含值 3 的任何序列。然而，在实践中，这只会适用于非常狭窄的一组用例，否则会导致低效的回溯甚至歧义。
• 序列模式**不会**遍历可迭代主题。所有元素都是通过下标和切片访问的，并且主题必须是 collections.abc.Sequence 的实例。当然，这包括列表和元组，但不包括例如集合和字典。虽然它将包括字符串和字节，但我们对这些做了例外（见下文）。

序列模式不能仅仅遍历任何可迭代对象。如果整体模式失败，则必须撤消从迭代中消耗的元素，这是不可行的。

为了识别序列，我们不能仅仅依靠 len() 以及下标和切片，因为序列在这方面与映射（例如 dict）共享这些协议。如果序列模式也匹配字典或其他实现映射协议（即 __getitem__）的对象，那将令人惊讶。因此，解释器执行实例检查以确保所讨论的主题确实是序列（已知类型）。（作为最常见情况的优化，如果主题恰好是列表或元组，则可以跳过实例检查。）

字符串和字节对象具有双重性质：它们本身都是“原子”对象，也是序列（具有强递归性质，因为字符串是字符串的序列）。字符串和字节的典型行为和用例与元组和列表的不同之处足以保证明确的区别。事实上，字符串充当序列通常是不直观的和非预期的，这一点从经常出现的问题和投诉中可以看出。因此，字符串和字节不匹配序列模式，将序列模式限制为对“序列”的非常具体的理解。内置的 bytearray 类型，作为 bytes 的可变版本，也应该是一个例外；但我们不打算枚举所有可能用于表示字节的其他类型（例如，一些，但不是全部，memoryview 和 array.array 的实例）。

映射模式

字典或一般的映射是 Python 中最重要和使用最广泛的数据结构之一。与序列相比，映射是为了快速直接访问由键标识的任意元素而构建的。在大多数情况下，元素是从字典中通过已知键检索的，而不考虑存储在同一字典中的任何顺序或其他键值对。字符串键尤其常见。

映射模式反映了字典查找的常用用法：它允许用户通过常量/已知键从映射中提取一些值，并使这些值与给定的子模式匹配。即使没有 **rest，主题中的额外键也会被忽略。这与序列模式不同，在序列模式中，额外项会导致匹配失败。但映射实际上与序列不同：它们具有自然的结构子类型化行为，即，在某处传递一个带有额外键的字典很可能会正常工作。如果需要对映射施加上限并确保不存在其他键，则可以使用通常的双星号模式 **rest。但是，带有通配符的特殊情况 **_ 不受支持，因为它不会有任何效果，但可能会导致对映射模式语义的错误理解。

为了避免过度昂贵的匹配算法，键必须是字面量或值模式。

使用 get(key, default) 而不是 __getitem__(key) 后跟 AttributeError 检查有一个微妙的原因：如果主题碰巧是 defaultdict，则对不存在的键调用 __getitem__ 会添加该键。使用 get() 可以避免这种意外的副作用。

示例 使用映射模式

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)

类模式

类模式满足两个目的：检查给定主题是否确实是特定类的实例，以及从主题的特定属性中提取数据。轶事证据表明，就程序中的静态出现次数而言，isinstance() 是 Python 中最常用的函数之一。此类实例检查通常在随后访问存储在对象中的信息或对其进行可能的操纵之前进行。典型的模式可能类似于

def traverse_tree(node):
    if isinstance(node, Node):
        traverse_tree(node.left)
        traverse_tree(node.right)
    elif isinstance(node, Leaf):
        print(node.value)

在许多情况下，类模式会嵌套出现，如动机中给出的示例所示

if (isinstance(node, BinOp) and node.op == "+"
        and isinstance(node.right, BinOp) and node.right.op == "*"):
    a, b, c = node.left, node.right.left, node.right.right
    # Handle a + b*c

类模式允许您简洁地指定实例检查和相关属性（以及可能的进一步约束）。因此，非常容易编写例如在第一个例子中编写 case Node(left, right): 以及在第二个例子中编写 case Leaf(value):。虽然这确实适用于具有严格代数数据类型的语言，但在 Python 对象的结构中存在问题。

在处理通用 Python 对象时，我们面临着潜在的大量无序属性：Node 的实例包含大量属性（其中大多数是“特殊方法”，例如 __repr__）。此外，解释器无法可靠地推断属性的顺序。对于表示圆的对象，例如，属性 x、y 和 radius 没有内在的明显顺序。

我们设想了两种处理此问题的方法：要么显式命名感兴趣的属性，要么提供一个额外的映射来告诉解释器要提取哪些属性以及提取顺序。这两种方法都受支持。此外，显式命名感兴趣的属性允许您进一步指定对象的所需结构；如果对象缺少模式指定的属性，则匹配失败。

• 显式命名的属性采用命名参数的语法。如果 Node 类的对象具有如上所述的两个属性 left 和 right，则模式 Node(left=x, right=y) 将提取这两个属性的值并分别将其分配给 x 和 y。数据从左到右流动看起来不寻常，但与映射模式一致，并且有先例，例如通过 with 或 import 语句中的 as 进行赋值（实际上还有 AS 模式）。

  显式命名相关属性主要用于位置形式（如下）不足的更复杂的情况。

• 类字段 __match_args__ 指定了一些属性及其顺序，允许类模式依赖于位置子模式，而无需显式命名相关的属性。这对于较小的对象或数据类的实例特别方便，其中感兴趣的属性相当明显并且通常具有明确定义的顺序。在某种程度上，__match_args__ 类似于形式参数的声明，它允许使用位置参数调用函数，而不是命名所有参数。

  这是一个类属性，因为它需要在类模式中命名的类上查找，而不是在主题实例上查找。

类模式的语法基于解构镜像构造语法的理念。这在几乎所有 Python 结构中都是如此，无论是赋值目标、函数定义还是可迭代解包。在所有这些情况下，我们发现“数据”发送和接收的语法几乎相同。

• 赋值目标，如变量、属性和下标：foo.bar[2] = foo.bar[3]；
• 函数定义：用 def foo(x, y, z=6) 定义的函数调用方式例如 foo(123, y=45)，其中调用站点提供的实际参数与定义站点处的形式参数匹配；
• 可迭代解包：a, b = b, a 或 [a, b] = [b, a] 或 (a, b) = (b, a)，仅举几个等价的可能性。

使用相同的语法进行读写、l 值和 r 值，或构造和解构，因其在思考数据、数据流和数据操作方面的益处而被广泛接受。这同样扩展到实例的显式构造，其中类模式 C(p, q) 故意镜像创建实例的语法。

对于内置类bool、bytearray等（例如，str(x)捕获x中的主题值）的特殊情况，可以通过以下方式由用户定义的类模拟。

class MyClass:
    __match_args__ = ["__myself__"]
    __myself__ = property(lambda self: self)

模式变量的类型注解。该提案是将模式与类型注解结合起来。

match x:
    case [a: int, b: str]: print(f"An int {a} and a string {b}:")
    case [a: int, b: int, c: int]: print("Three ints", a, b, c)
    ...

这个想法有很多问题。首先，冒号只能用在方括号或圆括号内，否则语法会变得模棱两可。并且由于 Python 不允许对泛型类型进行isinstance()检查，因此包含泛型的类型注解将无法按预期工作。