PEP 11 – CPython 平台支援
- 作者:
- Martin von Löwis <martin at v.loewis.de>, Brett Cannon <brett at python.org>
- 狀態:
- 作用中
- 類型:
- 流程
- 建立日期:
- 2002年7月7日
- 公告歷史:
- 2007年8月18日, 2014年5月14日, 2015年2月20日, 2022年3月10日
摘要
本 PEP 記錄了作業系統（平台）如何獲得 CPython 的支援、目前支援哪些平台，並記錄了過去的支援情況。
原理
隨著時間推移，CPython 原始碼中累積了各種平台特定的程式碼，這些程式碼在當時被認為是在特定平台上使用 CPython 所必需的。若無法存取該平台，便無法判斷是否仍需要這些程式碼。結果是，這些程式碼可能會在 CPython 的演進過程中損壞，或者隨著平台本身的演進而變得不再必要。
允許這些片段不斷增加會帶來難以維護的風險：如果沒有大量平台的專家，就無法判斷對 CPython 原始碼的特定更改是否會在所有受支援的平台上正常運作。
為了降低此風險，本 PEP 明確規範了平台要被 CPython 視為受支援所需滿足的條件，並提供了移除極少甚至無 CPython 使用者之平台程式碼的流程。
本 PEP 還列出了 CPython 直譯器確實支援的平台。這讓大眾了解 CPython 開發團隊直接支援哪些平台。
支援層級
平台支援分為層級 (tiers)。每個層級都有不同的要求，這也對應了不同的支援承諾。
要提升至某個層級，需要指導委員會 (Steering Council) 的支援，並預期透過團隊共識來推動。若某平台在一段時間內無法滿足目前層級的要求（根據發布經理或指導委員會的判斷），則會被降級至較低層級。對於在新的功能版本進入 b1 階段時，仍不符合任何層級要求的平台，將會發布公告以警告社群該平台即將終止支援（例如在 b1 公告中）。若該平台在第一個候選發布版本 (RC) 釋出前仍未符合至少一個層級的要求，則會在本 PEP 中被列為不支援。
第一層 (Tier 1)
- 狀態
- CI 失敗將阻礙發布。
- 不允許合併會破壞
main分支的更改；任何損壞都應立即修復或還原。 - 所有核心開發人員均有責任確保
main分支以及這些平台保持正常運作。 - 這些平台上的失敗會阻礙發布。
| 目標三元組 (Target Triple) | 備註 |
|---|---|
| aarch64-apple-darwin | clang |
| aarch64-unknown-linux-gnu | glibc, gcc |
| i686-pc-windows-msvc | |
| x86_64-pc-windows-msvc | |
| x86_64-unknown-linux-gnu | glibc, gcc |
第二層 (Tier 2)
- 狀態
- 必須擁有可靠的 buildbot。
- 至少有兩名核心開發人員簽名承諾支援該平台。
- 破壞這些平台中任何一個的更改，必須在 24 小時內修復或還原。
- 這些平台上的失敗會阻礙發布。
| 目標三元組 (Target Triple) | 備註 | 聯絡人 |
|---|---|---|
| aarch64-unknown-linux-gnu | glibc, clang | Victor Stinner, Gregory P. Smith |
| wasm32-unknown-wasip1 | WASI SDK, Wasmtime | Brett Cannon, Michael Droettboom |
| x86_64-apple-darwin | macOS, clang | Sam Gross, Barry Warsaw, Ronald Oussoren |
| x86_64-unknown-linux-gnu | glibc, clang | Victor Stinner, Gregory P. Smith |
第三層 (Tier 3)
- 狀態
- 必須擁有可靠的 buildbot。
- 至少有一名核心開發人員簽名承諾支援該平台。
- 對於失敗沒有回應服務等級協定 (SLA)。
- 這些平台上的失敗不會阻礙發布。
| 目標三元組 (Target Triple) | 備註 | 聯絡人 |
|---|---|---|
| aarch64-linux-android | Russell Keith-Magee, Petr Viktorin | |
| aarch64-pc-windows-msvc | Steve Dower | |
| arm64-apple-ios | iOS 裝置 | Russell Keith-Magee, Ned Deily |
| arm64-apple-ios-simulator | M1 macOS 上的 iOS 模擬器 | Russell Keith-Magee, Ned Deily |
| armv7l-unknown-linux-gnueabihf | 32 位元 Raspberry Pi OS, gcc | Gregory P. Smith |
| aarch64-unknown-linux-gnu | 64 位元 Raspberry Pi OS, gcc | Savannah Ostrowski |
| powerpc64le-unknown-linux-gnu | glibc, clang glibc, gcc |
Victor Stinner Victor Stinner |
| s390x-unknown-linux-gnu | glibc, gcc | Victor Stinner |
| wasm32-unknown-emscripten | emcc | Russell Keith-Magee |
| x86_64-linux-android | Russell Keith-Magee, Petr Viktorin | |
| x86_64-unknown-freebsd | BSD libc, clang | Victor Stinner |
所有其他平台
程式碼庫中對某平台的支援可能是部分的，這可能是由於圍繞該平台支援的積極開發，或是意外所致。對於未列在上述層級中的平台的程式碼變更，若造成維護負擔或阻礙了通用改進，可能會在沒有棄用程序的情況下被拒絕或從程式碼庫中移除。
未列於此處的平台可能在某種程度上由更廣泛的 Python 社群提供支援。如果您的目標平台未列於上方，請在網路上搜尋，看看是否已有人以某種形式提供支援。
備註
Microsoft Windows
Windows 10 之前的版本遵循 Microsoft 的固定生命週期原則 (Fixed Lifecycle Policy)，包含發布後 5 年的「主流支援」階段（產品廣泛商用），以及額外 5 年的「延伸支援」階段（仍提供付費支援及特定錯誤修復）。延伸安全性更新 (ESU) 是一項付費計畫，提供給高階企業客戶作為「最後手段」，在延伸支援結束後接收特定安全性更新。ESU 被視為延伸支援到期後的一個獨特階段。
Windows 10 及更新版本遵循 Microsoft 的現代生命週期原則 (Modern Lifecycle Policy)，該原則依產品、版本、版本別 (edition) 和頻道而異。通常，功能更新（如 1709, 22H2）每 6-12 個月發生一次，支援期為 18-36 個月；Server 和 IoT 版本以及 LTSC 頻道發布支援期為 5-10 年，且主要版本（Windows 10, Windows 11）的最新功能版本通常在發布後至少獲得 10 年的更新。Microsoft 的 Windows 生命週期常見問題集有更具體且最新的指引。
CPython 的 Windows 支援目前遵循 Microsoft 的生命週期。新的功能版本 X.Y.0 將支援所有其延伸支援階段尚未結束的 Windows 版本。隨後的錯誤修復版本將支援與原始功能版本相同的 Windows 版本，即使該版本已不再受 Microsoft 支援。CPython 處於維護模式期間發布的 Windows 新版本，核心團隊與發布經理可視情況決定是否提供支援。
截至 2024 年，我們對 Microsoft 生命週期的當前解讀是：用於 IoT 和嵌入式系統的 Windows 不在新的 CPython 版本支援範圍內，因為其目標是避免功能更新。Windows Server 通常會是仍接收免費安全性修復的最舊版本，這將決定具有對應 API 版本的早期受支援用戶端版本（通常已過期）。
每個功能版本皆由特定版本的 Microsoft Visual Studio 建置。該版本在發布時應處於主流支援階段。擴充模組開發人員通常需要使用相同的 Visual Studio 版本；他們既關心所需版本的可用性，也關心如何控制版本數量。CPython 原始碼樹將保留舊版 Visual Studio 的未維護建置檔案，且接受針對這些檔案的修補程式。此類建置檔案將在編譯器延伸支援結束 3 年後從原始碼樹中移除（但在版本控制系統中仍可取得）。
舊版 C 地區設定 (Legacy C Locale)
從 CPython 3.7.0 開始，*nix 平台預期至少提供 C.UTF-8（完整地區設定）、C.utf8（完整地區設定）或 UTF-8（僅限 LC_CTYPE 的地區設定）其中之一，作為舊版 C 地區設定的替代方案。
任何僅在舊版 C 地區設定中發生，且無法在適當配置的非 ASCII 地區設定中重現的 Unicode 相關整合問題，將被標記為「不會修復」(won’t fix) 並關閉。
不支援的平台
如果某平台退出層級支援，必須在本 PEP 中註明該平台已不再受到主動支援。此註記必須包含：
- 系統名稱，
- 不再支援此平台的首個發布版本編號，以及
- 主動移除歷史支援程式碼的首個版本。
在某些情況下，無法識別使用特定程式碼的確切系統列表（例如當 autoconf 測試某個在所有受支援系統上都被視為存在的特徵是否存在時）。在這種情況下，名稱將給出將變得不受支援的精確條件（通常是一個預處理器符號）。
同時，若有人嘗試在此平台上安裝 CPython，CPython 建置過程必須修改以發出警告。在依賴 autoconf 的平台上，configure 也應針對不受支援的平台發出警告。
這讓該平台的潛在使用者有機會挺身而出提供維護。我們不會將失去第三層支援的平台，視為比從未受支援的平台更差。
已終止支援的平台
- 名稱: MS-DOS, MS-Windows 3.x不支援於: Python 2.0程式碼移除於: Python 2.1
- 名稱: SunOS 4不支援於: Python 2.3程式碼移除於: Python 2.4
- 名稱: DYNIX不支援於: Python 2.3程式碼移除於: Python 2.4
- 名稱: dgux不支援於: Python 2.3程式碼移除於: Python 2.4
- 名稱: Minix不支援於: Python 2.3程式碼移除於: Python 2.4
- 名稱: Irix 4 和 –with-sgi-dl不支援於: Python 2.3程式碼移除於: Python 2.4
- 名稱: Linux 1不支援於: Python 2.3程式碼移除於: Python 2.4
- 名稱: 定義了 __d6_pthread_create 的系統 (configure.in)不支援於: Python 2.3程式碼移除於: Python 2.4
- 名稱: 在 thread_pthread.h 中定義了 PY_PTHREAD_D4, PY_PTHREAD_D6 或 PY_PTHREAD_D7 的系統不支援於: Python 2.3程式碼移除於: Python 2.4
- 名稱: 使用 –with-dl-dld 的系統不支援於: Python 2.3程式碼移除於: Python 2.4
- 名稱: 使用 –without-universal-newlines 的系統不支援於: Python 2.3程式碼移除於: Python 2.4
- 名稱: MacOS 9不支援於: Python 2.4程式碼移除於: Python 2.4
- 名稱: 使用 –with-wctype-functions 的系統不支援於: Python 2.6程式碼移除於: Python 2.6
- 名稱: Win9x, WinME, NT4不支援於: Python 2.6 (2.5 安裝程式中有警告)程式碼移除於: Python 2.6
- 名稱: AtheOS不支援於: Python 2.6 (將 “AtheOS” 改為 “Syllable”)建置損壞於: Python 2.7 (編輯 configure 以重新啟用)程式碼移除於: Python 3.0
- 名稱: BeOS不支援於: Python 2.6 (configure 中有警告)建置損壞於: Python 2.7 (編輯 configure 以重新啟用)程式碼移除於: Python 3.0
- 名稱: 使用 Mach C Threads 的系統不支援於: Python 3.2程式碼移除於: Python 3.3
- 名稱: SunOS 輕量級進程 (LWP)不支援於: Python 3.2程式碼移除於: Python 3.3
- 名稱: 使用 –with-pth (GNU pth threads) 的系統不支援於: Python 3.2程式碼移除於: Python 3.3
- 名稱: 使用 Irix threads 的系統不支援於: Python 3.2程式碼移除於: Python 3.3
- 名稱: OSF* 系統 (issue 8606)不支援於: Python 3.2程式碼移除於: Python 3.3
- 名稱: OS/2 (issue 16135)不支援於: Python 3.3程式碼移除於: Python 3.4
- 名稱: VMS (issue 16136)不支援於: Python 3.3程式碼移除於: Python 3.4
- 名稱: Windows 2000不支援於: Python 3.3程式碼移除於: Python 3.4
- 名稱: COMSPEC 指向 command.com 的 Windows 系統不支援於: Python 3.3程式碼移除於: Python 3.4
- 名稱: RISC OS不支援於: Python 3.0 (部分程式碼已實際移除)程式碼移除於: Python 3.4
- 名稱: IRIX不支援於: Python 3.7程式碼移除於: Python 3.7
- 名稱: 無多執行緒支援的系統不支援於: Python 3.7程式碼移除於: Python 3.7
討論
- 2022年4月: 考慮將 Tier 3 加入分層平台支援 (Victor Stinner)
- 2022年3月: 提議的分層平台支援 (Brett Cannon)
- 2015年2月: 更新 PEP 11 以釐清平台支援的取得方式 (Brett Cannon)
- 2014年5月: 我們官方支援哪些平台的政策在哪裡？ (Brett Cannon)
- 2007年8月: PEP 11 更新 - 呼籲移植維護人員挺身而出 (Skip Montanaro)
版權
本文件已進入公有領域或遵循 CC0-1.0-Universal 授權，以較寬鬆者為準。
來源: https://github.com/python/peps/blob/main/peps/pep-0011.rst
最後修改: 2025年10月9日 17:15:34 GMT