程式閒聊 - Python 3 的 11 年登基之路

我是機器學習、AI 紅起來之後才接觸 Python 的，進新手村時 Python 版本已到 3.12.6 (註：呃，其實我現在還沒走出新手村)，但隱約看過不少提到 Python 2/3 版本問題的文件，前陣子看原子能的 YT 影片提到 Python 從 2 升 3 有段漫長的升級歷程，對其中的故事感到好奇。

把疑惑丟給了 LLM，幾分鐘就有答案，猜想也有同學跟我一樣好奇(啊... 沒有嗎？好桑新)，就融合 LLM 查到的資料加上我的老人觀點寫一篇吧。

Python 發展在早期是採取 BDFL 制度 (Benevolent Dictator For Life，終身仁慈獨裁者)，語言創始人 Guido van Rossum 范羅蘇姆對於 Python 的發展方向有絕對的決定權。
題外話：BDFL 是我認為最好的開源專案運作模式，另一個經典案例是 Linux 的 Linus，BDFL 也是我認為 Linux 之所以能成為偉大作業系統的原因之一。所有設計必然有優點也有缺點，因此每次決策都是一次取捨(Trade Off)，而在衡量客觀條件之餘，面對僵局往往得靠理念或信仰進行裁決，此時需維持一致的中心思想才能保住初衷，貫徹使命與目標。任何靠協商共識決定，總會摻雜不同人或團體的價值觀、利害關係，結果依當下的權力與利益拉扯而訂，多頭馬車難保不會走向奇怪的方向。對於軟體開發，我還是認同人月神話主張的「 外科手術團隊」論述，架構與方向永遠只能由一個人做決定，主刀醫師只能有一個，且不能一直換手，不然包準病人會死在手術床上。

2008 范羅蘇姆在 Google I/O 開發者大會演講的照片 來源

范羅蘇姆在 2008/12/3 推出 Python 3.0，抱著既然要改版，就就破釜沈舟修掉 Python 2.x 裡累積已久、難以修正的設計缺陷，特別是 Unicode 字串處理、不直覺的整數除法行為、累贅的 print 陳述句... 等等。

不過，當時 Python 2.x 已被全世界廣泛使用，有成千上萬的第三方套件，要升級到 Python 3 一則程式要改，二則可能面臨無套件可用。

兩年後，2010/07 Python 發布 2.7 版，開發者面臨一個選擇：升級 2.7 還是升級 3。當時重要的第三方套件 - Django、NumPy、Pandas、Flask 都還在用 Python 2，而這些套件也不急著改用 3，因為使用者也都還在用 Python 2。

Python 3 改掉一些問題，但沒有革命性的突破，甚至有些人指出 Python 3 在某些情況下跑得比 Python 2 還慢。而 Python 3 與 2.x 不相容，要升級專案必須改寫，改寫意味著風險與成本，打一下算盤就知道該怎麼做了。於是大部分人選擇繼續爽用 Python 2.7，享受多不勝數的第三方套件，拖到 2015 年，2.7 預設的五年 EOS 期限都到了還沒人想升 3，迫於無奈 Python 團隊只能將 2.7 的支援期限延長五年到 2020。按這個發展，感覺只要所有人都留在 Python 2.7，技術支援會一直展延下去，Python 3.x 已經推出了也持續更新，但就是沒人用。

故事到了 2015 出現轉機，Python 3.5 於 9 月發布，加入了 async/await，成為堂堂正支援非同步程式設計的語言(C# 是 2013 .NET 4.5 加入、JavaScript 在 2017 ES8 加入)，同時 3.5 還加入類型提示(Type Hints)、效能最佳化，開始讓人有升級到 3.5 的動機。

2016 年，Python 社群採取了一個集體行動 - 「Python 3 宣言」（Python 3 Statement），數百個開源專案承諾在 2020 年之前停止支援 Python 2 (其實是受夠了要同時支援 2 跟 3 兩個版本，這種苦曾被跨瀏覽器搞過的人絕對都懂，更怕 2.7 EOS 依前例再延 5 年)，雖然不具強制，但創造一種社會壓力，如果 NumPy、Pandas、Django、Flask 都不再支援 Python 2 了，你還不下車？

2017 年，Instagram 宣布他們已經完全遷移到 Python 3。Facebook 也藉者在新員工訓練中教 Python 3、自動化測試強制檢查、設定截止日期... 等手段，將 Facebook 內部龐大的 Python 2 程式碼庫升到 Python 3。許多人因為 LLM 或 AI 學習 Python，TensorFlow/PyTorch 自始就只支援 Python 3，這批新加入的同學甚至只認識 3，不知有 2。

到 2018 年，PyPI 套件下載排行榜的前 360 名有 348 個支援 Python 3，75 % 的開發者開始使用 Python 3。2020/1/1 2.7 正式 EOS，這回沒再展延，從 Python 3 2008/12/3 推出，歷時 11 年，終於完成版本交替。

所有的版本升級故事都差不多，在我的經驗裡，有些心法可做為規劃版本升級的參考：

• 程式語言、程式庫愈成功，升級的阻礙愈大：If it works, don't touch it! 是實務界的鐵律，升級必定有成本有風險，能動就別動。沒人在用的東西，砍掉重練規格全變都不會有人在乎，版本升級阻力大，也算一種 Happy Problem。
  解決升級障礙的思路也很簡單：要嘛降低阻力，要嘛提高吸引力，不然讓程式爛到沒人想用也是解法(誤)
• 降低阻力：
  1. 控制 Break Changes，減少升級需要的改寫範圍。但有時不相容無法避免，只能控制，仔細想過代價再下決定。
  2. 如果同時支援舊版的成本可承受，預設停用舊版 API 或行為，讓真的想用的人透過旗標或設定開放，讓大部分人改用新版，未來全面關閉時反彈聲浪較小。
  3. 採漸進式停用，先註記為 Deprecated，執行或編譯時發出警告，給開發者一些時間適應，找機會升級，至少先有心理準備。與交通新法規上路後有段宣導期，期滿再正式開罰，可減少民怨。
• 提高吸引力：
  沒人沒事會想花時間花成本升級，新版必須包含某些殺手級的新功能或新改良，才足以讓開發者心甘情願投入成本享受好處。
  Python 3 一直到 3.5 推出 async/await，吸引 Facebook、Instgram 用它滿足非同步程式設計需求，並起了示範作用；而吸引大量新人入坑 Python 的 TensorFlow 及 PyTorch 只支援 3，也是絕佳助攻。
  少了這些，不知 Python 3 會不會再拖五年才登基。
• 語言/平台與第三方套件間的博奕僵局：
  語言/平台升級新版怕沒套件可用，套件開發者想說沒人用新版何必花時間為新版改寫，你不動我不動，我不動你不動，最後大家都不動。這點沒什麼好解法，只能等待時間發酵，除非背後有廠商願意投資金收買套件開發者提早配合新版，不然就只能像新版比例高到被套件開發者正視。

留下一個有趣問題，如果范羅蘇姆有機會穿越回到 2008 發布 3.0 之前，這次他會怎麼做？