將套件標記為暫行

套件將透過在其文件頁面及其說明文字 (docstring) 中的聲明標記為暫行。以下段落將作為附註添加在文件頁面的頂部：

<X> 套件是以暫行基礎納入標準函式庫。如果核心開發者認為有必要，可能會發生不相容於舊版本的變更（甚至包括移除該套件）。

「暫行基礎」一詞將連結至詞彙表項目「暫行套件 (provisional package)」，定義如下：

暫行套件是刻意排除在標準函式庫向後相容性保證之外的套件。雖然不預期這類套件會有重大更動，但只要被標記為暫行，核心開發者若認為有必要，仍可能發生不相容於舊版本的變更（甚至包括移除該套件）。此類變動不會無故發生——僅在發現納入套件前遺漏的嚴重缺陷時才會進行。

此過程使標準函式庫能持續進化，而不會長期受困於有問題的設計錯誤。詳情請參閱 PEP 411。

以下內容將添加到套件 docstring 的開頭：

此套件的 API 目前為暫行。詳情請參閱文件。

將套件從暫行狀態移至穩定狀態，僅需從其文件頁面和 docstring 中移除這些附註。

哪些套件應進入暫行狀態

我們預期大多數提議加入 Python 標準函式庫的套件都會在暫行狀態下經歷一個功能版本。然而，可能存在一些例外，例如使用預定義 API 的套件（例如 lzma，它大致遵循現有 bz2 套件的 API），或 API 在 Python 開發社群中已被廣泛接受的套件。

在任何情況下，提議加入標準函式庫的套件，無論是透過暫行狀態還是直接加入，都必須符合 PEP 2 設定的接受條件。

「晉升」準則

原則上，大多數暫行套件最終應晉升至穩定的標準函式庫。未能晉升的部分原因包括：

• 該套件可能被證明是不穩定或脆弱的，且缺乏足夠的開發者支援來維護它。
• 在預覽版期間發現了更好的替代套件。

基本上，決定將由核心開發者根據個案情況做出。這裡要強調的是，套件在某個版本中以「暫行」身分納入標準函式庫，並不保證它在下一個版本中會繼續作為 Python 的一部分。同時，對暫行套件進行變動的門檻相當高。我們預期大多數暫行套件的大部分 API 在晉升時不會改變。撤銷的情況預計將是罕見的。

對核心開發團隊的好處

目前，核心開發者對於向標準函式庫添加新介面非常慎重。這是因為一旦在版本中發佈，API 設計錯誤就會因向後相容性的考量而固定下來。

透過讓所有重大的 API 新增內容都在一個完整版本中經過某種暫行機制，我們可以在使用標準向後相容性保證鎖定 API 之前，獲得一個完整版本週期的社群回饋。

我們也可以開始將暫行套件與標準函式庫的其他部分整合，只要我們向打包者明確說明，不應將暫行套件視為可選。暫行 API 與標準函式庫其餘部分唯一的差別，在於暫行 API 被明確豁免於通常的向後相容性保證。

對終端使用者的好處

對於未來的終端使用者來說，最廣泛的好處在於更好的「開箱即用」體驗——與其被告知「噢，標準函式庫裡用於任務 X 的工具很難用，去下載這個第三方函式庫吧」，這些優質工具更可能只需要一個 import 即可使用。

對於要求開發者對其上游依賴進行盡職調查的環境（這會嚴重損害 PyPI 上許多素材的成本效益，甚至將其完全排除），關鍵益處在於確保所有處於暫行狀態的套件，至少在以下觀點上明確處於 python-dev 的管轄之下：

• 授權：由 PSF 在「貢獻者授權協議 (CLA)」下重新分發。
• 文件：套件的文件是透過標準 Python 文件工具發佈與組織（即 ReST 原始碼、使用 Sphinx 生成輸出，並發佈於 https://docs.python.club.tw）。
• 測試：套件測試套件在 python.org 的 buildbot 叢集上執行，結果透過 https://python.club.tw/dev/buildbot 發佈。
• 議題管理：Bug 與功能請求在 http://bugs.python.org 處理。
• 原始碼控制：軟體的主儲存庫發佈於 http://hg.python.org。