Python中不支持 switch 語句的原因是什么

這期內容當中小編將會給大家帶來有關Python中不支持 switch 語句的原因是什么，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

1、switch 是什么?

switch 的語法格式如下：

switch(expression){     case value1:        // 語句        break; // 可選     case value2:        // 語句        break; // 可選     default: // 可選        // 語句 }

使用流程圖來表示，大概是這樣的：

它的用法不難理解：switch 語句的值滿足哪一個 case 情況，就會執行對應的代碼塊，執行時遇到 break 就跳出，否則就繼續執行下一個 case  分支;一般會在最后放一個 default 分支，作為兜底。

大多數語言都提供了 switch 語句或者極其相似的東西，例如，在 C/C++/Java /Go 等靜態語言中，它們都支持 switch-case  結構;在 Ruby 中有類似的 case-when 結構，在 Shell 語言中，有相似的 case-in 結構，在 Perl 中，有  switch-case-else……

switch 語句的好處是支持“單條件多分支”的選擇結構，相比 if-else 的二分選擇結構，在某些時候會更為簡潔清晰。

但是，在 Python 中，我們看不到 switch-case 或者相近的語法結構，這是為什么呢?

2、Python 為什么不支持 switch?

官方文檔中有一篇 FAQ 包含了這個問題：Why isn’t there a switch or case  statement in Python?

FAQ 即 Frequently Asked Questions 的縮寫，表示常見問題，官方列了 27  個常見問題，完整清單在此：https://mp.weixin.qq.com/s/zabIvt4dfu_rf7SmGZXqXg

該文檔給出了幾個建議，告訴了我們幾個 switch/case 的替代方案：

• 使用 if-elif-else 條件判斷語句

• 使用字典，將 case 值與調用的函數映射起來

• 使用內置 getattr() 檢索特定的對象調用方法

曾有人提出過一些提案(即 PEP-275 和 PEP-3103)，想給 Python 引入 switch  語法，然而，對于“是否以及如何進行靶場測試”，大家沒有達成一致的共識。

靶場測試，即 range test，指的是對武器彈藥的技術性能作各種測試驗證，與藥物的臨床試驗一樣，都是在最終產品交付前的一項關鍵性測試。

官方文檔對于“為什么 Python 不引入 switch”的解釋，實際上來源于 Python 之父 Guido van Rossum 在 PEP-3103  中的意見：

出處：https://www.python.org/dev/peps/pep-3103

A quick poll during my keynote presentation at PyCon 2007 shows this proposal  has no popular support. I therefore reject it.

我在 PyCon 2007 的主題演講中做了一個快速的民意調查，結果表明這個提案沒有得到廣泛的支持。因此，我拒絕了它。

簡而言之，PEP 提案有了，語法實現也有了雛形，但是核心開發者們似乎沒有達成一致意見，最終導致提案流產了。

3、PEP-275 與 PEP-3103 說了什么?

PEP-3103 是在 2006 年提出的，PEP-275 則是在 2001  年提出的，它們的共同之處是提出了引入 switch 語句的某種必要性、分析了好幾種備選的實現方案，然而，結局是都被拒絕了。

出處：https://www.python.org/dev/peps/pep-0275

那么，我們就先來回顧一下核心開發者們都做出了哪些討論，看一看如果 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)

上述就是小編為大家分享的Python中不支持 switch 語句的原因是什么了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。