近來，Python 在各大編程語言榜單上持續(xù)霸榜，成為增速最快的語言之一。從數(shù)據(jù)分析到深度學(xué)習(xí)，從科研到工程項目，幾乎無處不在。但它真的適合所有的數(shù)據(jù)科學(xué)任務(wù)嗎？對此，本文作者結(jié)合自己二十多年帶實驗室的經(jīng)歷，深入探討了 Python 在數(shù)據(jù)科學(xué)中的優(yōu)勢與局限，并對比了 R 的使用體驗，得出這樣一個結(jié)論——Python 并不是做數(shù)據(jù)科學(xué)的最佳語言。那么，他為什么這么說？我們一起看看他的最新觀察。

原文鏈接：https://blog.genesmindsmachines.com/p/python-is-not-a-great-language-for

作者 | Claus Wilke 責(zé)編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

我已經(jīng)準備好踩進語言之爭這趟渾水了。但我先說一句最重要的：用你最熟的工具。比如你熟悉 Python？那就用 Python。再補充一句：做哪件事最合適用哪個工具就用哪個工具。如果剛好還是 Python，那也沒問題。

還有就是，如果你本來就天天用某個工具，順手拿它來干點別的活，也完全正常。你一天到晚拿錘子敲釘子，用它開瓶啤酒、撓撓背，也都說得過去。同樣地，你整天寫 Python，用它順帶做做混合線性模型，也沒毛病。

如果你用得順手，那繼續(xù)用就行。但如果你越用越覺得別扭、感覺一些事情明明不該這么難，那這篇文章可能就是給你看的。

首先，我提出一個觀點——大家對“Python 是數(shù)據(jù)科學(xué)語言”這件事過度依賴了。它的局限性其實相當(dāng)明顯。有許多數(shù)據(jù)科學(xué)任務(wù)，我寧可用 R 完成，也不愿用 Python。

之所以 Python 在數(shù)據(jù)科學(xué)領(lǐng)域如此普及，我認為更多是歷史偶然，加上一種“各方面都還行”的通用性，而不是它在數(shù)據(jù)科學(xué)上有某種天生優(yōu)勢。

與此同時，我認為 Python 在深度學(xué)習(xí)上確實表現(xiàn)不錯。PyTorch 之所以成為行業(yè)標準是有理由的。這里我談的數(shù)據(jù)科學(xué)，并不包括深度學(xué)習(xí)，而是指其他那些工作：數(shù)據(jù)清洗、探索性分析、可視化、統(tǒng)計建模等等。

正如開頭提到的，如果你本來就有充分理由每天都在用 Python（比如訓(xùn)練 AI 模型），那么順便用它把剩下的事情一起做完也可以。我自己在教授深度學(xué)習(xí)課程時就是這么做的。但這并不能抵消我在 Python 世界里做數(shù)據(jù)分析時常常感到的笨拙與不便。

來自一線的觀察

我先談?wù)勛约旱挠H身經(jīng)歷，不做任何原因分析。我?guī)ьI(lǐng)計算生物實驗室已經(jīng)二十多年了，期間合作過大約三十位能力很強的研究生和博士后。實驗室的規(guī)則是：每個人可以自由選擇任何想用的編程語言和工具，我從不干預(yù)。

結(jié)果往往是，大多數(shù)人會選擇 Python。

下面是我經(jīng)常遇到的情況：一位學(xué)生來辦公室向我展示一些結(jié)果。我說：“這很好，你能不能把圖換一種方式快速畫一下？”或者“能不能快速算一個我剛想到的量，并畫出來看看？”諸如此類的需求。通常這些都是我知道在 R 里幾分鐘就能搞定的任務(wù)，比如把箱線圖改成小提琴圖、把折線圖改成熱力圖、把直方圖換成密度估計、把原始值換成排序值再計算等等。

幾乎毫無例外，使用 Python 的學(xué)生總會回答：“這要花點時間，我得回去研究一下，弄好再告訴你?！?/p>

我要強調(diào)的是：這些學(xué)生都非常強。問題并不是他們不懂工具，而是工具本身似乎就比較笨拙，讓我以為是“非常簡單的請求”，卻經(jīng)常變得一點也不簡單。

無論原因是什么，我都不得不得出一個結(jié)論：Python 在數(shù)據(jù)分析上的某些基礎(chǔ)環(huán)節(jié)出現(xiàn)了結(jié)構(gòu)性問題。可能是語言本身的問題，也可能是庫生態(tài)的問題，或兩者共同作用，但結(jié)果是真實存在的，而且我長期都能看到類似情況。

事實上，我再舉一個例子，以避免你認為“這是學(xué)生水平問題”。

去年秋天，我和一位資深的數(shù)據(jù)科學(xué)家一起教授生物學(xué)的 AI 課程。他所有工作都用 Python，對 NumPy、pandas、matplotlib 都熟得不能再熟。在課上，他負責(zé)帶學(xué)生做 Python 練習(xí)，我負責(zé)講理論。這讓我可以觀察到一位 Python 專家如何現(xiàn)場解決各種數(shù)據(jù)分析問題。

我的反應(yīng)往往是：“為什么要寫得這么復(fù)雜？”許多我認為用 R 幾行就能寫出的東西，在 Python 里卻變得又長又繞。我自己要是不花大量時間重新訓(xùn)練大腦、適應(yīng)完全不同的編程思維，就根本寫不出那些代碼。這種陌生感并不是“陌生但優(yōu)雅”，而是“陌生、怪異、且繁瑣”。

而我很確定原因不在于同事，他非常厲害。真正的問題，似乎就在這些工具的底層設(shè)計上。

什么才是適合數(shù)據(jù)科學(xué)的語言？

退一步講，選擇數(shù)據(jù)科學(xué)語言時有一些基本考量。這里說的數(shù)據(jù)科學(xué)，是指剖析和總結(jié)數(shù)據(jù)、尋找模式、擬合模型、繪制可視化——也就是科研人員在日常數(shù)據(jù)分析中會做的所有工作。這與數(shù)據(jù)工程或應(yīng)用開發(fā)并不相同。

數(shù)據(jù)科學(xué)高度依賴交互式探索，需要大量快速試驗性的分析。因此，適合數(shù)據(jù)科學(xué)的語言必須支持解釋執(zhí)行，并能在交互式 Shell 或 Notebook 中使用。性能反而是次要的。當(dāng)你做一個線性回歸時，你根本不會在意是 50ms 還是 500ms；你關(guān)心的是：能不能立刻打開 Shell，寫幾行代碼，幾分鐘內(nèi)得到結(jié)果，而不是新建工程、寫一堆模板代碼、取悅編譯器，還要花比運行更久的時間等待編譯。

既然交互性和低啟動成本是必須，那候選自然落在 Python、R、Matlab、Mathematica 這類腳本或數(shù)據(jù)科學(xué)語言上。也包括 Julia，但說實話我對 Julia 了解不足，不好評價。它可能非常優(yōu)秀，但我也看到不少深度用戶對它有所保留。本文就不展開。Matlab、Mathematica 之類的商業(yè)語言，以及缺乏生態(tài)的 Octave 也先放一邊。現(xiàn)實選擇就是 R 和 Python。

繼續(xù)之前我想補充一下關(guān)于性能的看法。性能通常要以犧牲語言其他特性為代價：程序員額外負擔(dān)（如 Rust）、更高的隱蔽 bug 風(fēng)險（如 C），或兩者皆有。在數(shù)據(jù)科學(xué)里，高 bug 風(fēng)險不可接受，而程序員便利性遠比極致性能重要。電腦足夠快，而思考會痛。我寧愿少費心力告訴電腦該做什么，多等一會兒。有真正性能瓶頸時，我完全可以在明確需求后把關(guān)鍵路徑重寫成 Rust。

把“邏輯”與“搬運工作”分開

不讓分析變得更困難的關(guān)鍵，就是把“分析邏輯”與“實現(xiàn)細節(jié)”分離。我希望能用概念層面的描述來寫分析代碼：數(shù)據(jù)要怎么處理、目標是什么；而不想被迫去操心底層細節(jié)，比如數(shù)據(jù)類型、數(shù)字索引、循環(huán)、手動拆裝數(shù)據(jù)表等等。

只要我開始管這些事，那多半是在被“繁瑣的機械勞動”拖累。

舉個例子，來看 Palmer 群島的企鵝數(shù)據(jù)集。里面有三種企鵝分布在三座島上。假設(shè)我要計算“島 × 物種”兩個維度下的體重均值和標準差，并排除體重缺失的記錄。

理想的數(shù)據(jù)科學(xué)語言應(yīng)該能讓我以接近自然語言的方式完成這個任務(wù)，用的代碼量與我剛用英語描述的句子詞匯量差不多才算優(yōu)秀。R 和 Python 都做得到——只是難易度差別很大。

下面是使用 tidyverse 風(fēng)格的 R 代碼：

  )

再來看等價的 Python 代碼，使用 pandas 完成相同任務(wù)：

)

這兩個例子整體上非常相似。以這種規(guī)模的分析任務(wù)來說，Python 做得還不錯。我個人覺得 R 語言的代碼可讀性略好一些（注意 Python 里有多少引號和括號），但差別不算大。

兩者的流程也一致：取 penguins 數(shù)據(jù)集、去掉體重缺失的記錄、按“物種 × 島嶼”分組，然后分別計算均值和標準差。

對比一下只用 Python 基礎(chǔ)語法、完全不依賴數(shù)據(jù)處理庫時的等價版本：

          f"SD: {result['body_weight_sd']:6.2f} g")

這段代碼明顯長得多，里面到處是循環(huán)，還得把數(shù)據(jù)集拆開再重新拼回去。不管你喜歡哪種語言，應(yīng)該都能看出來：不用管這些瑣碎步驟、直接表達你要做什么的版本，比被一堆雜事拖住的版本好太多了。

簡單來說，我覺得 Python 代碼之所以動不動就變成“苦力活”，是因為無論你多想保持高層抽象、寫得清爽一點，語言本身或者它的庫，總會出來添亂，讓你不得不去處理那些底層細節(jié)。

【活動分享】2025 年是 C++ 正式發(fā)布以來的 40 周年，也是全球 C++ 及系統(tǒng)軟件技術(shù)大會舉辦 20 周年。這一次，C++ 之父 Bjarne Stroustrup 將再次親臨「2025 全球 C++及系統(tǒng)軟件技術(shù)大會」現(xiàn)場，與全球頂尖的系統(tǒng)軟件工程師、編譯器專家、AI 基礎(chǔ)設(shè)施研究者同臺對話。

本次大會共設(shè)立現(xiàn)代 C++ 最佳實踐、架構(gòu)與設(shè)計演化、軟件質(zhì)量建設(shè)、安全與可靠、研發(fā)效能、大模型驅(qū)動的軟件開發(fā)、AI 算力與優(yōu)化、異構(gòu)計算、高性能與低時延、并發(fā)與并行、系統(tǒng)級軟件、嵌入式系統(tǒng)十二大主題，共同構(gòu)建了一個全面而立體的知識體系，確保每一位參會者——無論是語言愛好者、系統(tǒng)架構(gòu)師、性能優(yōu)化工程師，還是技術(shù)管理者——都能在這里找到自己的坐標，收獲深刻的洞見與啟發(fā)。詳情參考官網(wǎng)：https://cpp-summit.org/