危險的轉變：Python正在從簡明轉向臃腫，從實用轉向媚俗

國慶長假期間，Python3.9正式推出，各大IT平臺和眾多自媒體紛紛火力全開，熱推Python3.9的新增特性。然而，除了媒體的自娛自樂，幾乎所有的程序員都對此表示無感。我甚至覺得 ，每一次的版本升級都是在抬升Python的學習門檻，令初學者望而生畏。

簡單和優雅，是Python創始人吉多 · 范羅蘇姆(龜叔)開立山門之時為Python確立的哲學理念。現在，Pyton的發展顯然已經背離了這一原則：不管有用無用，但凡別家有的，一概收入；不管是否適合，只要能充門面，悉數拿來。此情勢正如當年Pandas之父韋斯·麥金尼面對Pandas的快速擴張時所表達出的無奈：“Pandas正在背離我最初所期望的簡潔和易用，變得越來越臃腫和不可控制。”

曾經，我非常地喜歡Python。今天，這份愛依然在，但多了一些冷靜和理性。十幾年的陪伴，從默默無聞到炙手可熱，Python終于在軟件排行榜上占據了顯耀的位置。在席卷軟件行業的擴張風暴中，在Python連續不斷地版本升級中，我卻分明看到了一種危險的轉變：Python正在從簡明轉向臃腫，從實用轉向媚俗。

忍了很久，今日得閑，吐槽一下Python的新增語言特性。以下總結了導致Python危險轉向的十大槽點，排名不分先后。

危險的轉變：Python正在從簡明轉向臃腫，從實用轉向媚俗

媚俗的靜態類型檢查

大約從Py3.5開始，直至最新的Py3.9，感覺Python語言項目團隊就在做一件事兒：靜態類型檢查。為了實現類型檢查，他們推出了typing模塊，定義了一大堆的應用規則。相應的，有一批靜態類型檢查工具應運而生，比如Mypy、Pylint或者Pyflakes，PyCharm也可以很好的集成這些工具。對此，我只想說一句：Python是動態語言吧？既然是動態語言，那你檢查個毛線？即便檢查通過，就能像編譯語言那樣運行了？一切不過是虛幻的假象而已，請別用其他語言的理念戕害質樸的Python。Python追求的是用最簡捷的方式解決問題，而不是制造麻煩，然后再解決麻煩。Python強推靜態類型檢查，不過是迎合那些集成開發工具(IDE)，同時滿足不明就里的程序員的成就感和虛榮心罷了。

危險的轉變：Python正在從簡明轉向臃腫，從實用轉向媚俗

畫蛇添足的變量類型聲明

當一個擁有5年工作經驗的Python程序員讀到下面的代碼時，會有什么樣的感受呢？

>>> name: str

相信他一定會說，天哪，這是什么？是Python嗎？沒錯，這的確是Python。看起來像是指定了變量的類型，但即使像下面這樣用字符串給被指定為列表類型的變量賦值，運行時也不會發出任何的提示或警告。

>>> gilrfriends: list = '奧黛麗·赫本, 卡米拉·貝勒, 安吉麗娜·朱莉' # 打著右轉燈左轉

你看，打著右轉燈左轉，照樣通行無誤。這樣畫蛇添足的操作有什么用呢？原來僅僅是為了讓IED或者類型檢查工具知道變量的類型。工具原本是為程序員服務的，現在好了，你得先為工具服務。差評！

危險的轉變：Python正在從簡明轉向臃腫，從實用轉向媚俗

雞肋般的函數及參數的類型注解

我一直在尋找一種可以限定函數參數類型的方法，以避免程序運行時出現意外的情況。受限于Python的機制，大多數情況下我只能使用斷言(assert)在函數內部對參數類型作出限制，同時盡可能在doc中對參數類型及含義作詳盡描述，就像下面的代碼一樣。

def sphere(center, radius, color, slices=90):

現在，如果按照Python指導委員會所倡導的方式，上面的代碼應該寫成如下的樣式。

from typing import Union

看上去一切都是完美的，但結果令人遺憾。這個函數及參數的類型注解只是一個注解而已，中看不中用：不管你輸入了什么類型的參數，只要數量夠3個或者4個，就可以被執行。唯一的作用就是降低了代碼的可讀性，原本四個參數一眼可見，現在卻要花費20秒鐘來辨認。不會有類型驗證(除非使用類型檢查工具)，更不會有長度檢查。如果想要這些功能，一切還得靠自己。

危險的轉變：Python正在從簡明轉向臃腫，從實用轉向媚俗

不加限制的擴展運算符

任何一門編程語言都是在不斷地更新和擴展中發展起來的，Python也不例外。說實話，Python的一些語法擴展，還是非常精妙和必要的，比如Py3.8引入的海象運算符(:=)，就是一個典型的例子。引入海象運算符之前，若要將一個不足16位長的字符串s用#補足16位(若大于或等于16位則原樣輸出)，一般寫成下面這樣。

>>> s = 'Hello Wold'

這個代碼中兩次計算字符串s的長度，顯然，這不是一個高效的代碼。但是如果使用一個臨時變量保存字符串s的長度，又不夠優雅。海象運算符正是為了解決這一類問題而誕生的。

>>> s = 'Hello Wold'

可惜，不是所有的擴展都像海象運算符這樣美妙，甚至其中的很大一部分擴展并未展現出足夠的必要性和不可替代性，只是給程序員帶來更多使用上的困惑。比如，Py3.9新增的字典合并(|)和更新(|=)運算符，當屬此列。

>>> a = {'x':1, 'y':2}

嚴重懷疑Python團隊的人忘記了字典還有個update方法可以實現這兩個新的運算符的功能。

>>> a = {'x':1, 'y':2}

也許有人會說，就算字典更新運算符(|=)和update功能完全重疊，可字典合并運算符(|)返回的是一個新字典，而update改變了原先的字典。對于持有這種想法的人，我只能悄悄提醒一下，Python對此早有解決方案。

>>> {**a, **b}

危險的轉變：Python正在從簡明轉向臃腫，從實用轉向媚俗

越俎代庖的字符串方法

大量的內置函數或方法，固然可以為程序員帶來更多的便利，但也會使系統臃腫，同時增加了入門難度，使學習曲線變得陡峭。如何平衡這個尺度，是一個見仁見智的問題。在我看來，不斷增加函數和方法，不但違背了Python的初衷，破壞了API的穩定性，也讓程序員失去了選擇和樂趣。比如，Py3.9為str對象新增了removeprefix和removesuffix兩個方法，分別用于刪除字符串前綴和后綴。

>>> s = '[主播]上港獲得前場任意球(1:1)'

類似的應用需求有很多，如果都要加入到str對象的方法庫中，str對象將會變得無比龐大。此類函數的編寫，分明應該交由程序員去做，Python語言項目組只需要關注基礎的和核心的方法即可。實際上，這兩個方法實現起來，也不過是一行代碼而已。

>>> s = '[主播]上港獲得前場任意球(1:1)'

危險的轉變：Python正在從簡明轉向臃腫，從實用轉向媚俗

啼笑皆非的字符串前綴

Py2時代，u是最常見的字符串前綴，Py3時代，u前綴銷聲匿跡，b成為了最常見的字符串前綴。無論是Py2還是Py3，原生字符串前綴r都是Python程序員眼中的熟客。從Py3.6開始，突然又冒出來一個新的字符串前綴。

>>> score = '1:1'

以前的前綴，僅僅是一個標識，現在的f前綴則變成了一種運算符，感覺美妙的理性世界瞬間崩塌了！然而，這只是一個開始，更糟糕的事情發生在Py3.8版本上，他們居然又為這個f前綴增加了等號(=)的支持。

>>> 語文=95

MyGod，這哪兒是代碼，簡直是神符！說實話，格式化字符串時，除了C語言風格的%外，我連format函數都沒用過，現在卻有可能要面對同事寫出來的包含加強版f前綴的代碼。傷心的我，只能一笑了之。

危險的轉變：Python正在從簡明轉向臃腫，從實用轉向媚俗

不講邏輯的字典順序

Py3.6發布的時候，就有人到處宣傳說，字典有序了。起初我以為那不過自媒體出于獵奇的目的，隨便說說，吸引眼球的。在邏輯上，字典是數據的無序集合，僅依賴于鍵檢索，如果字典有序，那就不是字典了。沒想到，Py3.7居然真的將“字典保持插入順序”作為新增特性正式對外公布了。幸好，官方說的是“字典保持插入順序”，而不是“字典有序”，總算為邏輯保留了最后的底褲。

我說字典無序，不是指字典在物理實體上實現的時候真的無序，而是指它的順序對用戶而言沒有明確的界定，不能作為數據的特性使用。也許Py3.7使用了新的機制可以更高效地存儲和檢索字典數據，但這并不是程序員所關注的。新的機制帶來的字典順序穩定，并不能成為我們可以信賴和使用的字典屬性。

危險的轉變：Python正在從簡明轉向臃腫，從實用轉向媚俗

惟恐天下不亂的函數參數限定符

說到函數的定義和傳參，恐怕沒有比Python更靈活的語言了。方便的同時，位置參數、默認參數、可變參數、關鍵字參數等幾種參數類型和使用順序，也給程序員帶來了很多使用上的困惑。然而，Py3.8堅定地認為，函數參數的使用還不夠混亂，還需要再刺激一下，以期達到從大亂到大治的目的。于是，函數參數限定符登場了——為了增強效果，Python官方選擇斜杠(/)作為這個限定符的表現形式。

讓我們一起來嘗試著讀一讀下面這段代碼。

>>> def func(a, b, /, c, d, *, e, f):

這里，a, b是位置參數，e, f是關鍵字參數，c, d既可以是位置參數，也可以是關鍵字參數。好了，關于函數參數限定符就說這么多吧，反正也用不著——除非你是在用Python函數完全模擬C代碼編寫的函數。

危險的轉變：Python正在從簡明轉向臃腫，從實用轉向媚俗

毫無優雅感的泛型函數

說到泛型，Python程序員通常會有兩種表情：一種是驚訝：“Python有泛型嗎？”；另一種是哂笑：“Python有型嗎？”且不討論Python是否“有型”，作為動態語言，泛型難道不是與生俱來的嗎？也許Python團隊不這么認為，或者他們認為Python程序員不這么認為。為了配得上編程語言排行榜上大佬的位次，從Py3.4開始，Python團隊就為Python定制了一個泛型函數裝飾器。無奈這個機制實在太過牽強，用它寫出來得代碼丑得一批，估計沒幾個人會用它。

>>> from functools import singledispatch

上面這一大堆的代碼，只是定義了一個函數say_hello，可以根據傳入參數的類型不同而做出不同反應。如果不使用泛型裝飾器，實現起來更加簡單且易讀。

>>> def say_hello(x):

危險的轉變：Python正在從簡明轉向臃腫，從實用轉向媚俗

前后打臉的亡羊補牢

當我第一次讀到typing.List和typing.Dict的時候，有那么一小會兒，感覺像是在讀java或者是C++的代碼。為什么不是熟悉的list和dict呢？僅僅是為了類型提示(type hints) ，為了讓集成開發工具讀懂代碼，生生搞出了比list和dict還復雜的概念。最終的結果是，IDE讀懂了代碼，程序員卻看不明白了。

好在Py3.9對類型提示做了改進，為內置的以及標準庫中的集合類型提供了用于類型提示中的泛型的支持，解決了一直以來Python代碼中會出現兩種list(list 和 typing.List)類型的尷尬情況，也算是亡羊補牢吧。

對python感興趣的可加QQ：3145679695一起學習交流分享

總結

以上是生活随笔為你收集整理的python桌面程序臃肿_危险的转变：Python正在从简明转向臃肿，从实用转向媚俗的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。