為什麼我覺得Python爛的要死?原因有八

為什麼我覺得Python爛的要死?原因有八

本文來自微信公眾號:新智元(ID:AI_era),編輯:元子、大明、木青,來源:hackerfactor;HackerNews。


作為機器學習程序員的首選編程語言,Python成為世界範圍內最受大學生歡迎的編程語言。但凡事有例外,近日,一位開發者講述了他無法忍受Python的8大原因,引髮網友大量回應。


作為機器學習程序員的首選編程語言,Python近年來可謂如日中天,人氣連年暴漲。由於AI熱潮持續不斷,Python在今年更是取代Java,成為世界範圍內最受大學生歡迎的編程語言。很多機器學習領域的教材、文章和技術文檔,給出代碼時會以Python作為示例語言,可見Python受歡迎程度之高。


Python具有上手快、門檻低、語法結構相對簡單等優點,初學者易入門、老手的二次學習成本也低,再加上機器學習任務上優勢獨具,受熱捧簡直是水到渠成的事。


但凡事有例外,東西再好也不可能人人都愛。


近日在hackerfactor上,一位名叫Neal Krawetz的人就撰文,指出了自己無法忍受Python的八大原因,把Python里裡外外吐槽了一遍。


文章列出了作者認為Python存在重大缺陷的八條理由,包括版本兼容性問題、安裝版本混亂、在程序關鍵字命名規則、常用庫命名規則上獨樹一幟,且缺乏一致性、賦值傳遞混亂、本地文件命名策略易出錯等。


總之一通下來,把Python貶得夠嗆。這篇文章在當下Python大熱的背景下可算是一朵「奇葩「了。看多了Python讚歌是不是有點審美疲勞了?不妨換換口味。


原因1:版本之間不兼容


安裝Linux后,那麼它很可能默認會安裝多個版本的Python,可能有Python2和Python3,甚至更多零零碎碎的版本,如3.5或3.7。


這是有原因的:Python3與Python2不完全兼容,一些其他版本在這方面的缺陷也足夠明顯——向後兼容性不足(backwards compatibility,也稱為向下兼容性)


所以Ubuntu同時安裝了Python2和Python3,因為這些版本的核心功能是不同的。



缺乏向後兼容和分離版本通常是走向衰敗的預警。Commodore創建了第一台家用電腦(要遠早於IBM PC或Apple之前)。但Commodore PET與隨後的Commodore CBM計算機並不兼容,而CBM與VIC-20,Commodore-64,Amiga等也不兼容。因此,用戶要麼花費大量時間將代碼從一個平台導到另一個平台,要麼就直接放棄了這個平台——Commodore就是前車之鑒。當用戶選擇放棄平台時,它就註定會消失。


同樣,Perl曾經很受歡迎。但是當Perl3問世時,它並沒有完全向後兼容Perl2的代碼。接下來是Perl4。當Perl5問世時,很多人選擇轉向使用其他更穩定的編程語言。所以今天,只有一小部分人還在積極使用Perl來維護現有的Perl項目,而其他任何基於Perl的重大新項目再也沒有出現過。


同樣,Python為每個版本設計了不同的代碼孤島。社區一直拖拽着這些舊版本,所以你最終也只能得到那些舊的、過時的Python代碼,因為沒有人願意花時間將它導到最新版本上。


據我所知,沒有人在Python2上創建新的代碼,但我們還讓它苟延殘喘着,因為沒人將所需的代碼導到Python3.x. 在官方Python網站上,這些文檔被主動維護並可用於Python 2.7、3.5、3.6和3.7——因為他們無法放棄舊代碼。Python就像編程語言的殭屍——行屍走肉般向前走。


原因2:安裝太太太太麻煩了


通常來說,你直接apt、yum、rpm后得到就是最新穩定版。


但你如果'apt-get install python',就不知道是什麼版本,可能與你需要的所有代碼都不兼容。所以你在安裝的時候需要指定Python版本。


有一個項目需要用Python3.5(當時最新的版本),然而我的電腦上最終安裝了一大堆版本:Python2、Python2.6、Python3和Python3.5。兩個來自操作系統,一個為了項目安裝,一個是因為我安裝了一些不相關的軟件。


儘管它們都是「Python」,但它們並非完全相同。


如果你想安裝Python的軟件包,你應該使用「pip」(Pip代表「Pip Installs Packages」)。但是由於系統上有許多版本的Python,你必須記住使用正確版本的pip。否則,'pip'可能會運行'pip2'而不是你需要的'pip3.7'。(如果名稱不存在,你需要指定pip3.7的實際安裝路徑。)


我被一個朋友告知我需要配置環境,以便所有東西都能使用Python 3.5。這種方法的確很有效,但沒有持續多久,因為我開始了另一個需要Python 3.6版本的項目。兩個併發項目有兩個不同版本的Python——emmmm,這有點一言難盡吧。


pip安裝程序將文件放在用戶的本地目錄中。你不能使用pip來安裝系統範圍的庫,並且Gawd會阻止你犯下運行'sudo pip'的錯誤,因為這會搞砸整個電腦!


順便說一句,是誰維護這些pip模塊?答案是社區。也就是說,沒有明確的所有者,也沒有強制性的責任所屬。今年早些時候,一個版本的PyPi有一個後門發生了SSH憑據盜竊,但我對此一點都不驚訝,因為社區存儲庫根本不值得相信。出於同樣的原因,我也不使用Node.js和npm。


原因3:令人頭疼的語法問題,作用域使用空格導致可讀性差


我是可讀代碼的堅定信徒。乍一看,Python似乎非常易讀,而當你開始製作大型代碼庫,這種易讀性就會減弱了。


其他編程語言,像C, Java, JavaScript, Perl, and PHP,用{} 來表示作用域;List用()。Python用空格。如果你需要給一個複雜的代碼定義一個作用域,然後你縮進了下面幾行代碼,當縮進終止后,作用域就終止了。


Python手冊說你可以使用任意數量的空格或製表符來定義範圍。但是,每次縮進都要用四個空格!如果要縮進兩次以進行嵌套,那就得使用八個空格!


Python社區已經對這個術語進行標準化,儘管它沒出現在Python手冊中。文檔中的示例說可以使用TAB、「TAB+1空格」等等。但是社區卻對4個空格有着喪心病狂的偏執!因此,除非你打算永遠不向其他任何人展示你寫的代碼,否則每個縮進都要使用四個空格。


當我第一次看到Python代碼時,我認為使用縮進來定義範圍似乎是個好主意。事實上,我太天真了,這簡直是一個天大的缺點。


深度嵌套是可以進行的,但每行代碼會變得很寬,不得不在文本編輯器中換行。長函數和長條件操作都可能讓開始與結束變得難以匹配。我可憐那些錯誤計算空格數量(比如只輸了3個空格而不是四個)的人,因為這樣的錯誤需要數小時進行調試和追蹤。


我debug代碼習慣沒有縮進,這樣我就可以快速瀏覽代碼,並在完成後輕鬆識別和刪除debug代碼。


但是用Python呢?縮進錯誤的話,都會報錯。


原因4:特立獨行的加載庫方式


大多數編程語言都有一些方法可以包含其他代碼塊。對於C,它是「#include」。對於PHP,有'include','include_once','require'和'require_once'。而對於Python,則是「import」。


Python的import允許導入整個模塊、模塊的一部分或模塊中的特定功能。但查找導入代碼塊的方法卻很麻煩。使用C,直接看/usr/include/*.h就行了。但用Python?最好使用'python -v'列出所有位置,然後搜索該列表中每個目錄和子目錄中的每個文件。這真的很麻煩。


導入功能還允許用戶重命名導入的代碼,它們基本上定義了一個命名空間。乍一看,這似乎很不錯,但這最終會影響可讀性和長期支持。重命名模塊非常適合小腳本,但對於大程序來說真的很糟糕。這樣的操作「import numpy as n」,應該被打死。


但這不是最糟糕的部分。對於大多數語言,包含代碼真的只意味着包含代碼。而一些語言(如面向對象的C ++)則可以執行代碼。類似地,一些PHP代碼可能會定義全局變量,因此一項import可以運行代碼,但這通常被認為是一種不好的做法。相比之下,許多Python模塊包含在導入期間運行的初始化函數。你不知道什麼在運行,你不知道它在做什麼,你甚至都沒察覺到。除非存在命名空間衝突,否則在這種情況下,你需要花很長時間來查找原因。


原因5:關鍵字和庫命名「獨樹一幟」


在其他所有編程語言中,數組都稱為「array」。在Python中,數組被稱為「list」。在其他語言中,關聯數組有時稱為'hash'(Perl),但Python里叫做「dictionary」。 Python似乎沒有使用在計算機和信息科學領域的常用術語。


然後是庫的名稱。看看這些名字吧,PyPy、PyPi、NumPy、SciPy,SymPy、PyGtk、Pyglet,PyGame ......(是的,前兩個名稱發音一模一樣,但是它們的功能和用途有很大區別。)我知道「py」代表Python。但這兩個字母就不能固定在庫的開頭或是末尾嗎?


而且一些常見的庫並沒有沿用這個所謂的「Py」命名約定。比如matplotlib、nose、Pillow和SQLAlchemy。雖然從一些命名上能夠看出庫的一些功能(比如「SQLAlchemy」包含SQL,所以它可能是一個SQL接口),但很多名稱只是隨機化的單詞。如果你事先並不知道「BeautifulSoup」是幹什麼用的,你能從名稱中看出它是一個HTML / XML解析器嗎?


(順便說一句,BeautifulSoup庫的說明文檔很完備,非常易於使用。如果每個Python模塊都這麼好用,我也不會在這裡吐槽這麼多。但遺憾的是,這只是個例外,而不是常態。大多數Python庫的文檔都爛的要死。)


總的來說,我認為Python對庫的命名非常混亂,缺乏一致性的原則。我總覺得,開源項目的命名都存在這種規則混亂的問題。除非你了解這個項目,否則你從項目名字上根本看不出來。除非你知道要找的是什麼,否則你很可能永遠都無法找到想找的東西。從大多數Python庫的命名上看,我現在更加確信這個觀點了。


原因6:其他「獨樹一幟」之處略多


每種語言都有它的怪癖。在C語言中,使用&和*來訪問地址空間和值是奇怪的命名法。C也有「++」和 --"這樣的變量增減控制方式在Bash語言中,當引用括號和正則表達式的句點等特殊字符時,需要使用反斜杠。


JavaScript存在兼容性問題(並非每個瀏覽器都支持所有有用的功能)。但是,Python比我見過的任何其他語言的奇怪之處更多。以字符串為例:


•在C中,對字符串使用雙引號,對字符使用單引號。


•在PHP和Bash中,兩種類型的引號都可以用於字符串。但是,使用雙引號時可以在字符串中嵌入變量。相比之下,使用單引號括起來的字符串屬於文字。任何類似嵌入式變量的名稱都不可擴展。


•在JavaScript中,單引號和雙引號之間確實沒有區別。


•在Python中,單引號和雙引號之間沒有區別。但是,如果想讓字符串跨行,則需要使用三引號「」「string」「」或「''string'''。如果想使用二進制文件,那麼你需要用b(b'binary')或r(r'raw')來優先選擇字符串。有時還需要使用str(string)進行字符串轉換,或使用string.encode('utf-8')將其轉換為utf8。


如果你認為=、==和===這些符號PHP和JavaScript中有點怪,那麼等你在Python中使用引號時再說吧。


原因7:賦值方式怪異


大多數編程語言都按值傳遞函數參數。如果函數改變了值,則結果不會傳遞迴調用代碼。但Python不一樣。 Python默認使用pass-by-object-reference參數執行函數。這意味着更改源變量可能最終會改變值。


這是面向程序、面向函數和面向對象編程語言之間的重大差異之一。如果每個變量都是通過對象引用傳遞的,而且對變量的任何更改都會導致其他所有地方的變量值變化,那麼其實也可以全部使用全局變量來處理所有內容。使用不同的名稱調用同一個對象不會更改對象的值,因此實際上該對象就是全局的。C語言程序員有句老話,全局變量是邪惡的,不應該使用。


在Python中,必須按值傳遞變量。「a = b」只是為同一個對象空間指定另一個名稱,並不會將b的值賦到a中。如果要賦值,則需要使用copy函數。通常格式是「a = b.copy()」。但是,請注意我說的是「通常」。並非所有數據類型都能夠這樣賦值,部分功能可能不完整。這時需要使用一個名為「copy」的獨立庫:「a = copy.deepcopy(b)」。


原因8:本地程序命名易混亂


根據使用的庫或函數來命名程序是一種常見的編程技術。比如,我正在使用名為「libscreencapture.so」的C語言庫測試屏幕捕獲程序,我調用的程序可能會命名為「screencapture.c」,編譯后命名為「screencapture.exe」。


如果使用C,Java,JavaScript,Perl,PHP等語言,這種命名方式很好用,因為程序語言可以很容易地將資源庫與本地程序區分開來,因為彼此的路徑是不同的。但是如果用的是Python,永遠不要這樣命名。


為什麼? Python總是假定用戶首先要導入本地代碼。如果我有一個名為「screencapture.py」的程序使用「importscreencapture」,那麼它將導入自己而不是系統庫。至少,本地程序需要命名為「myscreencapture.py」才能避免這種錯誤。


當然了,吐槽了這麼多,但其實Python並非一無是處。


Python是一種非常流行的語言,擁有數量龐大的使用者。我身邊有一些朋友非常喜歡Python,這是他們首選的編程語言。多年來,我和他們討論過這些問題,每次他們都點頭表示同意。他們並不否認Python確實存在這些問題,只是覺得這些缺點不足以讓他們拋棄Python。


我的朋友經常在編程中將所有存在的非常酷的Python庫統統引用。我也認為一些庫確實非常有用。例如,BeautifulSoup是我用過的最好的HTML解析器之一,NumPy使得多維數組和複雜的數學過程更容易實現,而TensorFlow則對於機器學習非常有用。但是,我不會因為喜歡TensorFlow或SciPy,而在Python中創建一個單片程序。為了某些庫的便利性,放棄程序可讀性和可維護性,屬於得不償失。


一般來說,我在寫關於某個主題的負面批評文章時,也會嘗試寫一些正面的東西。比如當我寫FFmpeg的局限性時,我也明確提到它是最好的視頻處理庫。但我這裡寫不出關於Python的什麼優點了,因為我真的覺得Python很爛。


此文一發,在評論區引發了激烈的爭論:


「是你不懂Python」


Mario Abarca


你的這些問題可以總結為一點:你不喜歡Python因為它和C風格不一樣


  1. 版本不兼容不是bug,是特性;我就覺得沒人維護的東西就不應該再用了


  2. 用虛擬環境安裝不同的python版本而不是安裝在同一個環境下


  3. 現代編輯器默認TAB=4個空格。你也不需要非得用4個空格,但要確保一致性


  4. 官方的文檔特別好,真的。要是標準庫里沒有,翻翻The Hitchhiker』s Guide to Python這本書


  5. 我覺得Python的命名風格特別好,更直觀。list不是數組,就是序列;關聯數組明明就是dict


  6. 二進制字符串前面加個b,是因為Unicode規範中,1位元組≠1byte


  7. 這樣做的好處是,我可以隨時隨地引用一個東西,而不需要每次都去複製粘貼原來的名字


  8. 同上


notacoward


  1. 1和2是同一個問題,有關整個生態,跟語言本身無關。因為這類社區維護的項目都是不同的人花費寶貴的業餘時間去維護,每個人都有每個人的習慣和價值觀


  2. 這個只能說你自己太個性了。我們大家保持默認的統一風格,對於別人維護起來明顯更容易


  3. C/C++的include很難處理模塊接口


  4. list和array不是一個東西。下一個


  5. 每個語言都有自己的一套轉換方式。Python可能不是最完美的,但是其他的更差,呵呵


  6. 對象引用效率更高。尤其是當變量名不一致的時候,你直接複製會有問題。但是你引用一下,就好多了


  7. 最好不要把自己的程序命名成標準庫里的程序或者模塊的名字


folkrav


首先要糾正下你,PyPy和PyPi發音不一樣。前一個是「派派」,后一個是「派-屁-愛」


其次,名稱很重要嗎?第三方誒大哥,啥名字都可以出現誒大哥。你就能保證你起名的時候,能做到信達雅嗎大哥?


jaxtellerSoA


我就不明白了。用縮進來定義作用域,怎麼就不好了?多一目了然啊!別的語言{}裡面不也得縮進嗎?再說了,你就不覺得按住shift才能打出{}很難受嗎?


riskable


我跟C粉兒討論過「縮進vs括號」這個問題。他說沒有括號怎麼能輕鬆找出作用域呢?


標準Py粉兒答案是:啊原來你們喜歡括號是因為你們的代碼壞習慣啊。


我想了想,可能這麼問更恰當:假如不使用文本編輯器/IDE來突出顯示括號或它們之間的空間,你還是堅持用括號不用縮進嗎?


我估計他終於get到我的點了,說:啊我明白了,你之所以用縮進是因為Python編輯器太爛了啊!真可憐。


Sign。


「我也不喜歡Python」


cutety


Python是我上手的第一個語言,但我以後再也不會用了。當然作者的這些問題,在我看來都不是問題,個人習慣而已。


  1. 包管理模式簡直爛到家。那麼多包管理器可以借鑒啊,可以讓pip不那麼爛啊


  2. 就不能有個標準包管理器有個標準manifest嗎?又不會懷孕!


twunde


安裝確實是個讓人頭疼的問題。是的很多人提到了安裝虛擬環境,venv/virtualenv。Ruby有RVM,可以輕鬆的在同樣環境下使用不同版本。我寧願挨個給Ruby,PHP,Perl…做環境配置,也不願意給Python配置。


nicoburns


哦!多行Lambda!我在JS里的最愛。Python里,沒!有!了!


setpatchaddress


我從1.5就開始用Python了。縮進來表示語句塊,是我最最最不能忍受的!


dbcurtis


我就喜歡C那種的括號,不喜歡Python的縮進方式。


colanderman


我覺得Python最大的問題其實是內部模型對於它的意圖而言過於複雜了,就是一個有經驗的開發者都很難理解,別說初學者了。


你怎麼看?


參考鏈接:

https://www.hackerfactor.com/blog/index.php?/archives/825-8-Reasons-Python-Sucks.html

https://news.ycombinator.com/item?id=18706174


本文來自微信公眾號:新智元(ID:AI_era),編輯:元子、大明、木青,來源:hackerfactor;HackerNews。

*文章為作者獨立觀點,不代表虎嗅網立場
本文由 新智元 授權 虎嗅網 發表,並經虎嗅網編輯。轉載此文請於文首標明作者姓名,保持文章完整性(包括虎嗅注及其餘作者身份信息),並請附上出處(虎嗅網)及本頁鏈接。原文鏈接:https://www.huxiu.com/article/277248.html
未按照規範轉載者,虎嗅保留追究相應責任的權利
未來面前,你我還都是孩子,還不去下載 虎嗅App 猛嗅創新!

想在手機閱讀更多程式設計資訊?下載【香港矽谷】Android應用
分享到Facebook
技術平台: Nasthon Systems