盤點 Python 的標的受眾 | Linux 中國

Python 是為誰設計的？

幾年前，我在 python-dev 郵件串列中，以及在活躍的 CPython 核心開發人員和認為參與這一過程不是有效利用個人時間和精力的人中強調[1]說，“CPython 的發展太快了也太慢了” 是很多衝突的原因之一。

我一直認為事實確實如此，但這也是一個要點，在這幾年中我也花費了很多時間去反思它。在我寫那篇文章的時候，我還在波音防務澳大利亞公司（Boeing Defence Australia）工作。下個月，我離開了波音進入紅帽亞太（Red Hat Asia-Pacific），並且開始在大企業的開源供應鏈管理[2]方面取得了再分發者redistributor層面的視角。

Python 的參考解析器使用情況

我嘗試將 CPython 的使用情況分解如下，儘管看起來有些過於簡化（註意，這些分類的界線並不是很清晰，他們僅關註於考慮新軟體特性和版本釋出後不同因素的影響）：

CPython 主要服務於哪些受眾？

從根本上說，CPython 和標準庫的主要受眾是哪些呢？是那些不管出於什麼原因，將有限的標準庫和從 PyPI 顯式宣告安裝的第三方庫組合起來所提供的服務還不能夠滿足需求的那些人。

為了更進一步簡化上面回顧的不同用法和部署模型，宏觀地將最大的 Python 使用者群體分開來看，一類是在一些感興趣的環境中將 Python 作為一種 指令碼語言 使用的人；另外一種是將它用作一個 應用程式開發語言 的人，他們最終釋出的是一種產品而不是他們的指令碼。

把 Python 作為一種指令碼語言來使用的開發者的典型特性包括：

相比之下，使用 Python 作為一個應用程式開發語言的開發者特徵包括：

作為以上分類的一個結果，CPython 和標準庫的主要用途是，在相應的 CPython 特性釋出後，為教育和臨時ad hoc的 Python 指令碼環境提供 3-5 年基礎維護服務。

對於臨時指令碼使用的情況，這個 3-5 年的延遲是由於再分發者給使用者開發新版本的延遲造成的，以及那些再分發版本的使用者們花在修改他們的標準操作環境上的時間。

對於教育環境中的情況是，教育工作者需要一些時間去評估新特性，然後決定是否將它們包含進教學的課程中。

這些相關問題的原因是什麼？

這篇文章很大程度上是受 Twitter 上對我的這個評論[10]的討論的啟發，它援引了定義在 PEP 411[11] 中臨時Provisional API 的情形，作為一個開源專案的例子，對使用者發出事實上的邀請，請其作為共同開發者去積極參與設計和開發過程，而不是僅被動使用已準備好的最終設計。

這些回覆包括一些在更高階別的庫中支援臨時 API 的困難程度的一些沮喪性表述，沒有這些庫做臨時狀態的傳遞，因此而被限製為只有臨時 API 的最新版本才支援這些相關特性，而不是任何早期版本的迭代。

我的主要回應[12]是，建議開源提供者應該強制實施有限支援，透過這種強制的有限支援可以讓個人的維護努力變得可持續。這意味著，如果對臨時 API 的老版本提供迭代支援是非常痛苦的，那麼，只有在專案開發人員自己需要、或有人為此支付費用時，他們才會去提供支援。這與我的這個觀點是類似的，那就是，志願者提供的專案是否應該免費支援老的、商業性質的、長週期的 Python 版本，這對他們來說是非常麻煩的事，我不認為他們應該這樣做[13]，正如我所期望的那樣，大多數這樣的需求都來自於管理差勁的慣性，而不是真正的需求（真正的需求，應該去支付費用來解決問題）。

而我的第二個回應[14]是去實現這一點，儘管多年來一直在討論這個問題（比如，在上面連結中最早在 2011 年的一篇的文章中，以及在 Python 3 問答的回覆中的這裡[15]、這裡[16]、和這裡[17]，以及去年的這篇文章 Python 包生態系統[18]中也提到了一些)，但我從來沒有真實地嘗試直接去解釋它在標準庫設計過程中的影響。

如果沒有這些背景，設計過程中的一部分，比如臨時 API 的引入，或者是受啟發而不同於它inspired-by-not-the-same-as的引入，看起來似乎是完全沒有意義的，因為他們看起來似乎是在嘗試對 API 進行標準化，而實際上並沒有。

適合進入 PyPI 規劃的方面有哪些？

任何提交給 python-ideas 或 python-dev 的提案所面臨的第一個門檻就是清楚地回答這個問題：“為什麼 PyPI 上的模組不夠好？”。絕大多數的提案都在這一步失敗了，為了透過這一步，這裡有幾個常見的話題：

只通過了前面的 “PyPI 是不是明顯不夠好” 的檢查，一個模組還不足以確保被納入標準庫中，但它已經足以將問題轉變為 “在未來幾年中，你所推薦的要包含的庫能否對一般的入門級 Python 開發人員的經驗有所提升？”

標準庫中的 ensurepip 和 venv 模組的引入也明確地告訴再分發者，我們期望的 Python 級別的打包和安裝工具在任何平臺的特定分發機制中都予以支援。

當新增它們到標準庫中時，為什麼一些 API 會被修改？

現有的第三方模組有時候會被批次地採用到標準庫中，在其它情況下，實際上新增的是吸收了使用者對現有 API 體驗之後進行重新設計和重新實現的 API，但是會根據另外的設計考慮和已經成為其中一部分的語言實現參考來進行一些刪除或細節修改。

例如，與流行的第三方庫 path.py、pathlib 的前身不同，它們並沒有定義字串子類，而是以獨立的型別替代。作為解決檔案互操作性問題的結果，定義了檔案系統路徑協議，它允許使用檔案系統路徑的介面去使用更多的物件。

為了在 “IP 地址” 這個概念的教學上提供一個更好的工具，ipaddress 模組設計調整為明確地將主機介面定義與地址和網路的定義區分開（IP 地址被關聯到特定的 IP 網路)，而最原始的 ipaddr 模組中，在網路術語的使用方式上不那麼嚴格。

另外的情況是，標準庫將綜合多種現有的方法的來構建，以及為早已存在的庫定義 API 時，還有可能依賴不存在的語法特性。比如，asyncio 和 typing 模組就全部考慮了這些因素，雖然在 PEP 557 中正在考慮將後者所考慮的因素應用到 dataclasses API 上。（它可以被總結為 “像屬性一樣，但是使用可變註釋作為欄位宣告”）。

這類修改的原理是，這類庫不會消失，並且它們的維護者對標準庫維護相關的那些限制通常並不感興趣（特別是相對緩慢的釋出節奏）。在這種情況下，在標準庫檔案的更新版本中使用 “See Also” 連結指向原始模組的做法非常常見，尤其是在第三方版本額外提供了標準庫模組中忽略的那些特性時。

為什麼一些 API 是以臨時的形式被新增的？

雖然 CPython 維護了 API 的棄用策略，但在沒有正當理由的情況下，我們通常不會去使用該策略（在其他專案試圖與 Python 2.7 保持相容性時，尤其如此）。

然而在實踐中，當新增這種受已有的第三方啟發而不是直接精確複製第三方設計的新 API 時，所承擔的風險要高於一些正常設計決定可能出現問題的風險。

當我們考慮到這種改變的風險比平常要高，我們將相關的 API 標記為臨時，表示保守的終端使用者要避免完全依賴它們，而共享抽象層的開發者可能希望對他們準備去支援的那個臨時 API 的版本考慮實施比平時更嚴格的限制。

為什麼只有一些標準庫 API 被升級？

這裡簡短的回答得到升級的主要 API 有哪些：

如果在將模組用於應用程式開發目的時（如 datetime），現有模組的限制主要是顯而易見的，如果再分發者透過第三方方案很容易地實現了改進，（如 requests），或者如果標準庫的釋出節奏與所需要的包之間真的存在衝突，（如 certifi），那麼，建議對標準庫版本進行改變的因素將顯著減少。

從本質上說，這和上面關於 PyPI 問題正好相反：因為從應用程式開發人員體驗的角度來說，PyPI 的分發機制通常已經夠好了，這種分發方式的改進是有意義的，允許再分發者和平臺提供者自行決定將哪些內容作為他們預設提供的一部分。

假設在 3-5 年時間內，預設出現了被認為是改變帶來的可感知的價值時，才會將這些改變納入到 CPython 和標準庫中。

標準庫任何部分都有獨立的版本嗎？

是的，就像是 ensurepip 使用的捆綁樣式（CPython 發行了一個 pip 的最新捆綁版本，而並沒有把它放進標準庫中），將來可能被應用到其它模組中。

最有可能的第一個候選者是 distutils 構建系統，因為切換到這種樣式將允許構建系統在多個發行版本之間保持一致。

這種處理方式的其它可能候選者是 Tcl/Tk 圖形套件和 IDLE 編輯器，它們已經被拆分，並且一些開發者將其改為可選安裝項。

這些註意事項為什麼很重要？

從本質上說，那些積極參與開源開發的人就是那些致力於開源應用程式和共享抽象層的人。

那些寫一些臨時指令碼或為學生設計一些教學習題的人，通常不認為他們是軟體開發人員 —— 他們是教師、系統管理員、資料分析人員、金融工程師、流行病學家、物理學家、生物學家、市場研究員、動畫師、平面設計師等等。

對於一種語言，當我們全部的擔心都是開發人員的經驗時，那麼我們就可以根據人們所知道的內容、他們使用的工具種類、他們所遵循的開發流程種類、構建和部署他們軟體的方法等假定，來做大量的簡化。

當應用程式執行時作為指令碼引擎廣泛流行時，事情會變得更加複雜。做好任何一項工作已經很困難，並且作為單個專案的一部分來平衡兩個受眾的需求會導致雙方經常不理解和不相信。

這篇文章不是為了說明我們在開發 CPython 過程中從來沒有做出過不正確的決定 —— 它只是去合理地回應那些對新增到 Python 標準庫中的看上去很荒謬的特性的質疑，它將是 “我不是那個特性的預期標的受眾的一部分”，而不是 “我對它沒有興趣，因此它對所有人都是毫無用處和沒有價值的，新增它純屬騷擾我”。

via: http://www.curiousefficiency.org/posts/2017/10/considering-pythons-target-audience.html

作者：Nick Coghlan[20] 譯者：qhwdw 校對：wxy、pityonline

本文由 LCTT 原創編譯，Linux中國 榮譽推出