哪些模組應該透過 __preview__ 進入

我們預期大多數建議加入 Python 標準函式庫的模組都應經過在 __preview__ 中的一個次要版本週期。不過，可能會有例外，例如使用預定義 API 的模組（例如 lzma，它通常遵循現有 bz2 模組的 API），或是其 API 在 Python 開發社群中已獲得廣泛認可的模組。

無論如何，建議加入標準函式庫的模組，無論是透過 __preview__ 還是直接加入，都必須滿足 PEP 2 所設定的接受條件。

必須強調的是，本提案的目的並非讓將新模組加入標準函式庫的過程變得更加困難。相反地，它試圖提供一種能加入更多實用函式庫的方法。顯然適合作為進入候選的模組可以照舊加入。而那些因 API 不確定性可能被擱置很長時間的模組，現在有了一種途徑，透過在 __preview__ 套件中的孵化期，仍能隨 Python 一起發布。

「畢業」標準

原則上，__preview__ 套件中的大多數模組最終都應畢業進入穩定的標準函式庫。不畢業的一些原因包括：

• 模組可能被證明是不穩定或脆弱的，且沒有足夠的開發者支援來維護它。
• 在預覽發布期間，可能會發現更好的替代模組。

本質上，決定將由核心開發者視個別情況做出。這裡要強調的重點是，模組在某個版本中出現在 __preview__ 套件中，並不保證它會在下一個版本中繼續成為 Python 的一部分。

範例

假設 example 模組是標準函式庫的候選者，但一些 Python 開發者並不確信它為其要解決的問題提供了最佳 API。那麼該模組可以在 3.X 版本中加入 __preview__ 套件，並可透過以下方式匯入：

from __preview__ import example

假設該模組隨後在 3.X+1 版本中升級至標準函式庫，它將被移至函式庫中的永久位置：

import example

屆時將無法再從 __preview__ 匯入它。

對核心開發團隊的益處

目前，核心開發者對於向標準函式庫新增介面非常謹慎。這是因為一旦介面在某個版本中發布，由於向後相容性的考量，API 設計錯誤將會被鎖定。

透過某種預覽機制對所有重大 API 新增項目進行一個完整發布週期的門控，我們可以在鎖定這些 API 並提供標準的向後相容性保證之前，獲得一個完整的社群回饋週期。

我們也可以提早開始將預覽模組與標準函式庫的其餘部分進行整合，只要我們向套件維護者明確說明不應將預覽模組視為可選項目即可。預覽 API 與標準函式庫其餘部分的唯一區別在於，預覽 API 明確豁免於通常的向後相容性保證。

本質上，__preview__ 套件旨在降低長期鎖定輕微 API 設計錯誤的風險。目前，這種考量即使在核心開發團隊原則上同意某項新增內容是一個好點子時，也可能阻止該新增項目。

對終端使用者的益處

對於未來的終端使用者而言，最廣泛的益處在於更好的「開箱即用」體驗 —— 與其被告知「喔，X 任務的標準函式庫工具很糟糕，請改下載這個第三方函式庫」，這些更優質的工具更有可能只需透過匯入即可使用。

對於那些要求開發者對上游依賴進行盡職調查的環境（這嚴重損害了 PyPI 上許多資料的成本效益，甚至完全排除在外），關鍵益處在於確保 __preview__ 套件中的任何內容，至少從以下觀點來看，明確處於 python-dev 的保護之下：

• 授權：由 PSF 根據貢獻者授權協議（Contributor Licensing Agreement）重新分發。
• 說明文件：模組的說明文件是透過標準 Python 說明文件工具發布與組織的（即 ReST 原始碼，輸出由 Sphinx 生成並發布於 https://docs.python.club.tw）。
• 測試：模組測試套件在 python.org 的 buildbot 叢集上執行，結果透過 https://python.club.tw/dev/buildbot 發布。
• 問題管理：錯誤報告與功能請求在 http://bugs.python.org 上處理。
• 原始碼控制：該軟體的主儲存庫發布於 http://hg.python.org。

使用 __future__

Python 已經有一個以 __future__ 模組形式存在的「前瞻性」命名空間，因此詢問為何不能將其重新用於此新目的，是合理的。

有兩個理由說明這樣做是不恰當的：

1. __future__ 模組實際上與獨立的編譯器指令功能連結，該功能確實會改變 Python 直譯器編譯模組的方式。我們不希望預覽套件出現這種情況 —— 我們只是想要一個普通的 Python 套件。

2. __future__ 模組帶有一個明確的承諾，即名稱將永遠維護，遠在相關功能成為編譯器的預設行為之後也是如此。同樣地，這與預覽套件的初衷恰恰相反 —— 幾乎可以肯定的是，所有加入到預覽套件中的名稱最終都會在某個時候被刪除，這很可能是因為它們被移到了標準函式庫中的永久位置，但也可能是因為它們被還原為第三方套件狀態（如果社群回饋顯示擬議的新增內容已無可救藥）。

套件版本化

一個建議的替代方案 [1] 是為 __preview__ 套件增加明確的版本編號，即 __preview34__。我們認為，簡單地定義模組在 Python 3.X 的 __preview__ 中，要麼在 Python 3.X+1 中畢業到正常的標準函式庫命名空間，要麼從 Python 原始碼樹中完全消失，會更好。對 __preview__ 套件進行版本編號會使過程複雜化，且與本提案的主要意圖不太一致。

使用不含前後底線的套件名稱

有人提議 [1] 使用如 preview 或 exp 之類的套件名稱，而非 __preview__。此議案在討論中被拒絕，因為「雙底線」套件名稱（即名稱前後帶有雙底線）在 Python 中具有特殊含義。此外，非雙底線名稱會暗示正常的標準函式庫 API 穩定性保證，這並非 __preview__ 套件的意圖。

維護 Pickle 相容性

基於 3.X 版本中 __preview__ 內模組的已封裝（pickled）類別實例，將無法在 3.X+1 版本中解封裝，因為該模組屆時將不在 __preview__ 中。可以添加特殊程式碼來實現這一點，但這違背了本提案的初衷，因為這意味著向後相容性。因此，本 PEP 不建議維護 Pickle 相容性。