Python이 스위치 문을 지원하지 않는 이유는 무엇입니까?-파이썬 튜토리얼-php.cn

이 기사의 Python Tutorial 칼럼에서는 Python이 스위치 문을 지원하지 않기로 결정한 이유에 대해 설명합니다.

Python이 스위치 문을 지원하지 않는 이유는 무엇입니까?

왜 이 주제에 대해 이야기하고 싶나요?

주로 스위치는 다른 언어에서 너무 일반적이지만 Python은 이를 지원하지 않기 때문입니다. 이 고유성 자체는 주목할 가치가 있습니다. 이 질문에 답하면 Python의 프로그래밍 개념을 더 명확하게 보고 프로그래밍에서 Python의 역할을 이해하는 데 도움이 됩니다. 문법 디자인에서.

이 기사에서는 PEP-275 및 PEP-3103을 자세히 분석하는 것 외에도 Python(PEP-622)의 최신 개발 동향, 즉 소개될 수 있는 패턴 일치 구문도 소개할 것입니다. 모든 사람의 지식 범위를 넓혀 스위치 구문을 더욱 포괄적으로 이해할 수 있습니다.

1.스위치란?

시작하기 전에 스위치가 무엇인지부터 이야기해야 할까요?

즉각적으로 생각나는 학생도 있을텐데...

야~야~ 게임에 대한 생각은 이제 그만하자. 프로그래밍 언어에서 말하는 스위치 문이다.

일반적으로 스위치의 구문 형식은 다음과 같습니다.

switch(expression){    case value1:       // 语句
       break; // 可选
    case value2:       // 语句
       break; // 可选
    default: // 可选
       // 语句}复制代码

로그인 후 복사

흐름도를 사용하여 표현하면 다음과 같습니다.

사용법은 이해하기 어렵지 않습니다. switch 문이 만족되면 해당 코드 블록을 실행하고 실행 중에 중단이 발생하면 점프합니다. 그렇지 않으면 일반적으로 다음 케이스 분기를 계속 실행하며 기본 분기는 안전망으로 끝에 배치됩니다.

대부분의 언어는 스위치 문이나 매우 유사한 것을 제공합니다. 예를 들어 C/C++/Java/Go와 같은 정적 언어에서는 모두 Ruby에서 스위치 케이스 구조를 지원합니다. , Shell 언어에는 유사한 Case-In 구조가 있고 Perl에는 Switch-Case-Else가 있습니다...

switch 문의 장점은 "단일 조건부 다중 분기" 선택 구조를 지원한다는 점입니다 , if-else의 이분법에 비해 때로는 더 간결하고 명확한 구조를 선택합니다.

하지만 Python에서는 switch-case나 유사한 구문 구조를 볼 수 없습니다. 왜 그럴까요?

2. Python은 왜 스위치를 지원하지 않나요?

공식 문서에 다음 질문이 포함된 FAQ가 있습니다. Python에는 왜 스위치나 케이스 문이 없나요?

FAQ는 약어입니다. 자주 묻는 질문(FAQ) 27가지 일반적인 문제의 공식 목록은 여기에 있습니다: mp.weixin.qq.com/s/zabIvt4df…

이 문서는 몇 가지 제안 사항을 제공하고 여러 스위치/케이스 대안을 알려줍니다.

if-elif-else 조건문을 사용하세요.

사전을 사용하여 케이스 값을 호출된 함수에 매핑합니다.
내장된 getattr()을 사용하여 특정 개체 호출 메서드를 검색합니다.

범위 테스트를 수행할지 여부와 방법

"에 대한 만장일치의 합의는 없습니다. 레인지 테스트(Range Test)라고도 불리는 레인지 테스트는 무기, 탄약의 기술적 성능을 검증하기 위한 다양한 테스트를 말하며, 약물의 임상시험과 마찬가지로 최종 제품이 납품되기 전 중요한 테스트입니다.

공식 문서의 “파이썬이 스위치를 도입하지 않는 이유”에 대한 설명은 실제로 PEP-3103에서 파이썬의 아버지인 귀도 반 로섬(Guido van Rossum)의 의견에서 나온 것입니다:

출처: www.python.org/dev /peps/ pe…

PyCon 2007 기조연설 중 간단한 여론조사를 보면 이 제안은 대중적인 지지를 받지 못하는 것으로 나타났습니다. 따라서 저는 이를 거부합니다.

PyCon 2007 기조연설 중 간단한 여론조사를 보면 이 제안은 대중적인 지지를 받지 못하는 것으로 나타났습니다. .널리 지원되지 않습니다. 그러므로 나는 그것을 거절했다.
간단히 말하면,

PEP 제안이 제안되고 구문 구현이 구체화되었지만 핵심 개발자들이 합의에 도달하지 못한 것으로 보이며 결국 제안이 중단되었습니다.

3. PEP-275와 PEP-3103은 무엇을 말했나요?

PEP-3103은 2006년에 제안되었고, PEP-275는 2001년에 제안되었습니다. 공통점은 switch 문 도입의 필요성을 제시하고 여러 대안 구현 솔루션을 분석했다는 것입니다. 그러나 결과는 다음과 같습니다. 모두 거절당했습니다.

출처: www.python.org/dev/peps/pe…

那么，我们就先来回顾一下核心开发者们都做出了哪些讨论，看一看如果 Python 要实现 switch 结构，会是怎么样子的？（PS：PEP 里还涉及其它内容，本文只摘取与 switch 直接相关的部分）

PEP-275 提出的语法结构如下：

switch EXPR:
    case CONSTANT:
        SUITE
    case CONSTANT:
        SUITE
    ...    else:
        SUITE复制代码

로그인 후 복사

其中 else 分支是可选的，如果没有它，并且前面的分支都不满足的话，就什么也不做。另外 case 值 constant 支持不同类型，因为 expr 表达式的类型是动态的。

PEP-275 还提出让 switch 不支持掉落（fall-through）行为，即每个 case 分支相互独立而完整，不用像 C 语言那样需要写 break。

该 PEP 还列举了一些其它的 issue：

重用现有关键字，不引入“switch”和“case”
使用新的关键字，避免与 C 的 switch 概念混淆
支持单分支多值选择（例如：case 'a', 'b', 'c': ...）
还有建议支持范围取值判断（例如：case 10..14: ...）

除了首选方案，该 PEP 还记录了几种风格各异的语法方案：

case EXPR:
    of CONSTANT:
        SUITE
    of CONSTANT:
        SUITE    else:
        SUITE

case EXPR:    if CONSTANT:
         SUITE    if CONSTANT:
        SUITE    else:
        SUITE

when EXPR:    in CONSTANT_TUPLE:
        SUITE    in CONSTANT_TUPLE:
        SUITE
    ...else:
     SUITE复制代码

로그인 후 복사

PEP-275 记录下了不少重要的思路和问题，为 PEP-3103 的出现做了很好的铺垫。

那么，我们再来看看由 Guido 编写的 PEP-3103 说了些什么吧。

它首先认可了 PEP-275 中的两个基础设定，例如，实现“隐式的 break”，不让 case 分支出现 fall-through 这种转移控制权的情况（其它语言似乎都要求显式地写 break）；else 分支是可选的，复用 else 关键字，而不用引入“default”。

对于 PEP-275 提倡的那种风格，Guido 比较认可，但也认为它的问题是缩进层次太多，因此建议减少代码分支缩进的空格数，例如本来缩进 4 空格，改为缩进 2 空格。

PEP-3103 还列举了另外三种实现方案，分析了它们的差异以及问题，具体内容从略，这里只给大家看看它们的风格：

# case 分支不缩进switch EXPR:
case EXPR:
    SUITE
case EXPR:
    SUITE
....else:
    SUITE# switch 语句后不加冒号switch EXPR
case EXPR:
    SUITE
case EXPR:
    SUITE
....else:
    SUITE# 省略 case 关键字switch EXPR:
    EXPR:
        SUITE
    EXPR:
        SUITE
    ...    else:
        SUITE复制代码

로그인 후 복사

在基础语法之外，Guido 花了很多篇幅来讨论扩展语法（Extended Syntax），即在一个 case 分支中实现匹配多个值的复杂情况：

case EXPR, EXPR, ...:# Guido 优选的case in EXPR_LIST:

case *EXPR:

case [*]EXPR, [*]EXPR, ...:

case *(EXPR, EXPR, ...):复制代码

로그인 후 복사

他重点考虑到的问题包括：switch 中表达式的结果是元组或可迭代对象的情况、case 的值被看成元组解包的情况、在 case 分支作“*”星号操作……

接着，Guido 又用了非常非常多的篇幅来分析该如何实现 switch，其中讨论到的主要思路有：

使用等价的 if-elif 链来定义 switch 语句（可能会做些优化）
同上，另外所有表达式都必须是可哈希的（hashable）
看作是预先计算的字典的分派（dispatch）

PEP 中这部分的内容非常多，因为在每个思路上，Guido 还考虑到了好几种实现路径，这导致了他在复杂分析后的结论是：It is too early to decide（现在做决定为时尚早）。

阅读完 PEP-3103 后，我总体的感觉是：Guido 的思路非常发散、层次丰富，但是，缺少了他在面对其它问题时那“快刀斩乱麻”式的洞察力。

也就是说，在诸多的可能性方案中，他力求面面俱到，最终无法说服自己做出一个独裁的决定。阻力主要来自于他自己，而不是其他人。

不过，之所以会出现这种情况，也许跟他的预设立场有关：他似乎认为“Python is fine without a switch statement”，因此尽管写了很长的 PEP，但只是在把问题复杂化，把议题搁置起来。

最后，他在 PyCon 上做了一个小范围调查，借此“名正言顺”地拒绝了自己发起的 PEP，试图堵住众人的悠悠之口……

4、未来会有 switch 语句么？

归结起来，之所以 Python 没有 switch 语句，原因有：switch 的实现细节/功能点未经敲定、没有 switch 也挺好的、有其它不错的方法替代 switch、Guido 的小任性……

但是，我们还是要追问一句：未来会有 switch 语句么？或者类似的多分支选择结构？

为什么要有此一问呢？原因是有太多语言自带 switch 语句，而且也有很多人尝试编写提供 switch 功能的库（我记得在 PyCoder's Weekly 里曾见到过两次）。

我（Python猫）本人自始至终并不喜欢 switch，几乎可以肯定地说，Python 未来也不会有 switch，但是，它很可能会引入一个类似于 switch 且更为复杂的语法结构！

2020 年 6 月，PEP-622 被提出了，它建议引入在 Scala、Erlang 和 Rust 等语言中的模式匹配语法（pattern matching）。

截至 2020 年 10 月，该 PEP 已被分解成另外三个 PEP（634-636），目前都处于草案阶段。考虑到核心开发者们的参与情况以及话题讨论的情况，这些提案极有可能会在未来版本（比如正在开发中的 3.10）中实现。

以一个求平均数的函数为例，模式匹配语法可以实现成这样：

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 x:                # captures the entire sequence
            return sum(x) / len(x)复制代码

로그인 후 복사

match-case 结构神似于 switch-case 结构，然而它基于模式（pattern）而非表达式（expression），因此有更多待考虑的细节问题，也有更为广阔的应用空间。

对此话题感兴趣的读者，建议去查阅这几个新的 PEP。

最后，让我们回到标题中的问题：Python 为什么不支持 switch 语句？

官方文档的 FAQ 对此问题有一个解答，告诉我们有几个不错的替代写法，同时也留下了一条线索：曾有 PEP 提议引入 switch，只是没有成功实现。

沿着这条线索，本文拆解了 PEP-275 和 PEP-3103 这两篇文档，带大家看到了 Python 社区里提出过的风格各异的 switch 方案，以及诸多的悬而未决的问题。

最后，我们还关注到了最新的 PEP-622 的动态，看起来 switch 的“孪生兄弟” match 语法有望引入到 Python 中！switch 话题的讨论似乎要终止了，但是另一个更大的话题正在进行中！