PEP 1 – PEP 目的和指南

作者:: Barry Warsaw, Jeremy Hylton, David Goodger, Alyssa Coghlan
狀態:: 活躍
型別:: 流程
建立日期:: 2000年6月13日
釋出歷史:: 2001年3月21日，2002年7月29日，2003年5月3日，2012年5月5日，2013年4月7日

什麼是PEP？

PEP代表Python增強提案（Python Enhancement Proposal）。PEP是向Python社群提供資訊，或描述Python新特性、其流程或環境的設計文件。PEP應提供對該特性的簡潔技術規範和理由。

我們打算將PEP作為提出主要新特性、收集社群對某個問題的意見以及記錄Python設計決策的主要機制。PEP作者負責在社群內建立共識並記錄不同意見。

由於PEP以文字檔案形式維護在版本控制倉庫中，其修訂歷史就是特性提案的歷史記錄。透過正常的git命令可以檢索舊版本，也可以在GitHub上瀏覽。

PEP受眾

PEP典型的主要受眾是CPython參考直譯器的核心開發者及其選舉產生的指導委員會，以及Python語言規範其他實現方式的開發者。

然而，Python社群的其他部分也可以選擇使用此流程（特別是資訊性PEP）來記錄預期的API約定，並管理需要跨多個專案協作的複雜設計協調問題。

PEP型別

PEP有三種類型

標準跟蹤（Standards Track）PEP描述了Python的新特性或實現。它也可以描述一個互操作性標準，該標準將在標準庫之外為當前的Python版本提供支援，之後再由一個PEP在未來版本中新增標準庫支援。
資訊性（Informational）PEP描述了Python的設計問題，或向Python社群提供一般性指南或資訊，但不提出新特性。資訊性PEP不一定代表Python社群的共識或建議，因此使用者和實現者可以自由地忽略資訊性PEP或遵循其建議。
流程（Process）PEP描述了圍繞Python的流程，或提議對某個流程進行更改（或事件）。流程PEP類似於標準跟蹤PEP，但適用於Python語言本身以外的領域。它們可能提出一種實現，但不是針對Python程式碼庫的；它們通常需要社群共識；與資訊性PEP不同，它們不僅僅是建議，使用者通常不能自由地忽略它們。示例包括程式、指南、決策過程的更改以及Python開發中使用的工具或環境的更改。任何元PEP也被視為流程PEP。

PEP工作流程

Python指導委員會

本PEP中多次提及“指導委員會”或“委員會”。這指的是PEP 13中描述的選舉產生的指導委員會的現任成員，他們作為PEP是否被接受或拒絕的最終權威。

Python核心開發者

本PEP中多次提及“核心開發者”。這指的是PEP 13中描述的當前活躍的Python核心團隊成員。

Python的BDFL

本PEP的早期版本曾使用“BDFL-Delegate”來稱呼PEP決策者。這是對Python先前治理模型的歷史引用，在該模型中，所有設計許可權最終都源於Python程式語言的原始建立者Guido van Rossum。相比之下，指導委員會的設計許可權源於其由當前活躍的核心開發者選舉產生。現在，PEP-Delegate取代了BDFL-Delegate。

PEP編輯

PEP編輯是負責管理PEP工作流程的行政和編輯方面的人員（例如，分配PEP編號和更改其狀態）。詳見PEP編輯職責與工作流程。

PEP編輯職位由現任編輯邀請，可以透過在GitHub上提及@python/pep-editors來聯絡他們。所有的PEP工作流程都可以透過GitHub PEP倉庫的議題和拉取請求進行。

從Python的新想法開始

PEP流程從Python的一個新想法開始。強烈建議一個PEP只包含一個核心提案或新想法；PEP越集中，往往越成功。大多數增強和錯誤修復不需要PEP，可以直接提交到Python問題追蹤器。如果PEP提案顯得過於分散或過於寬泛，PEP編輯保留拒絕的權利。如有疑問，請將您的PEP拆分成幾個重點明確的PEP。

每個PEP都必須有一個倡導者——撰寫PEP的人，按照下面描述的風格和格式，在適當的論壇中引導討論，並努力在理念周圍建立社群共識。PEP倡導者（即作者）應首先嚐試確定該理念是否“PEP可行”。在Python Discourse的Ideas類別發帖通常是最佳途徑，除非有更專業的場所適用，例如Python Discourse上的Typing類別（用於靜態型別理念）或Packaging類別（用於打包理念）。

在撰寫PEP之前公開審查一個想法是為了節省潛在作者的時間。許多提出改變Python的想法因各種原因被拒絕。首先詢問Python社群一個想法是否具有原創性有助於防止在根據之前的討論（搜尋網際網路並不總是有效）註定會被拒絕的事情上花費太多時間。它還有助於確保該想法適用於整個社群，而不僅僅是作者。僅僅因為一個想法對作者來說聽起來不錯，並不意味著它會在Python使用的多數領域對大多數人有效。

一旦倡導者向Python社群詢問某個想法是否有被接受的機會，就應該將PEP草案提交到上述適當的場所。這讓作者有機會充實PEP草案，使其格式正確、質量高，並解決對提案的初步擔憂。

提交PEP

在上述初步討論之後，工作流程會根據PEP的共同作者中是否有核心開發者而有所不同。如果PEP的一個或多個共同作者是核心開發者，他們將負責遵循下面概述的流程。否則（即所有共同作者都不是核心開發者），PEP作者將需要為PEP尋找贊助者。

理想情況下，會確定一位核心開發者贊助者，但經指導委員會批准，也可以選擇非核心贊助者。GitHub“PEP編輯”團隊的成員和型別委員會（PEP 729）的成員被預先批准為贊助者。贊助者的工作是為PEP作者提供指導，幫助他們完成PEP流程的後勤工作（有點像導師）。成為贊助者**不會**使該人失去以後成為共同作者或PEP-Delegate的資格（但不能同時兼任）。PEP的贊助者記錄在標題的“Sponsor:”欄位中。

一旦贊助者或共同撰寫PEP的核心開發者認為PEP已準備好提交，該提案應透過GitHub拉取請求作為草案PEP提交。草案必須按照以下描述的PEP風格編寫，否則將立即審查失敗（儘管小錯誤可能會由編輯修正）。

標準的PEP工作流程是

您，PEP作者，克隆PEP倉庫，並建立一個名為pep-NNNN.rst的檔案，其中包含您的新PEP。NNNN應該是未被已釋出或正在PR中的PEP使用的下一個可用PEP編號。
在“PEP:”標題欄位中，輸入與您的檔名匹配的PEP編號作為您的草案PEP編號。
在“Type:”標題欄位中，根據情況輸入“Standards Track”、“Informational”或“Process”，並在“Status:”欄位中輸入“Draft”。詳情請參閱PEP標題序言。
更新.github/CODEOWNERS，以便將對PEP倉庫具有寫入許可權的任何共同作者或贊助者列入您的新檔案。這確保了將來任何更改該檔案的拉取請求都將分配給他們。
將其推送到您的GitHub分支並提交拉取請求。
PEP編輯審查您的PR以檢查結構、格式和其他錯誤。對於reST格式的PEP，PEP 12提供了模板。它還提供了PEP中使用的reST標記的完整介紹。批准標準是
- 它是健全且完整的。想法必須在技術上合理。編輯不考慮它們是否可能被接受。
- 標題準確描述了內容。
- PEP的語言（拼寫、語法、句子結構等）和程式碼風格（示例應符合PEP 7和PEP 8）應正確且符合規範。提交拉取請求時，PEP文字將自動檢查reStructuredText格式是否正確。包含無效reST標記的PEP將不予批准。
編輯們通常對這種初步審查相當寬容，期望問題會透過審查過程得到糾正。**注意：**PEP的批准不保證沒有令人尷尬的錯誤！正確性是作者和審查者的責任，而非編輯的責任。

如果PEP尚未準備好批准，編輯會將其退回給作者進行修改，並附上具體說明。
一旦獲得批准，他們將為您的PEP分配一個編號。

一旦審查過程完成，並且PEP編輯批准了它（請注意，這**並非**等同於接受您的PEP！），他們會將您的拉取請求合併到主分支。

PEP編輯不會無故拒絕釋出PEP。拒絕PEP狀態的原因包括重複工作、技術上不健全、未提供適當的動機或未解決向後相容性問題，或者不符合Python哲學。在批准階段可以諮詢指導委員會，他們是草案PEP可行性的最終仲裁者。

對PEP倉庫具有寫入許可權的開發者可以透過建立和提交新的PEP直接宣告PEP編號。這樣做時，開發者必須處理通常由PEP編輯負責的任務（參見PEP編輯職責與工作流程）。這包括確保初始版本符合提交PEP的預期標準。或者，即使是開發者也應透過拉取請求提交PEP。這樣做時，通常期望您自行處理流程；如果您需要PEP編輯的幫助，請在GitHub上提及@python/pep-editors。

當需要更新時，如果PEP作者（或協作開發者）對PEP倉庫具有寫入許可權，他們可以提交新版本。儘早分配PEP編號對於方便引用很有用，尤其是在同時考慮多個草案PEP時。

標準跟蹤PEP由設計文件和參考實現兩部分組成。通常建議至少與PEP一起開發一個原型實現，因為原則上聽起來不錯的想法在實施測試時有時會變得不切實際。

討論PEP

一旦PEP編號被分配，並且草案PEP被提交到PEP倉庫，就應該為PEP建立一個討論執行緒，以提供一個集中的地方來討論和審查其內容，並且應該更新PEP，以便Discussions-To標題連結到它。

PEP作者（或贊助者，如果適用）可以選擇任何合理的討論場所，只要符合以下標準：

論壇與PEP主題相符。
該執行緒在網路上公開可用，以便所有感興趣的各方都可以參與。
討論受Python社群行為準則的約束。
在PEP的Discussions-To標題下提供當前討論執行緒的直接連結。

Python Discourse的PEPs類別是大多數新PEP的首選，而歷史上常用的是Python-Dev郵件列表。某些專業主題有專門的場所，例如Python Discourse上的Typing類別和Packaging類別，分別用於型別和打包PEP。如果PEP作者不確定最佳場所，PEP贊助者和PEP編輯可以提供相應的建議。

如果PEP進行了重大重寫或對其提議規範進行了其他重大、實質性更改，通常應在選定的場所建立一個新執行緒，以徵求額外的反饋。如果發生這種情況，必須更新Discussions-To連結，並新增一個新的Post-History條目指向此新執行緒。

如果未選擇其作為討論場所，則在草案PEP提交到倉庫時，以及進行足夠大的更改以觸發新執行緒時，應向PEPs類別釋出簡短的公告帖子，其中至少包含指向渲染PEP和Discussions-To執行緒的連結。

PEP作者負責在提交審查之前收集PEP的社群反饋。然而，為了避免冗長和開放式討論，應考慮以下策略：在早期設計階段徵求私下或更具體化的反饋，與在PEP主題方面有專業知識的其他社群成員協作，併為PEP主題選擇適當的專門討論（如果適用）。PEP作者應在此處自行判斷。

一旦PEP被分配編號並提交到PEP倉庫，實質性問題通常應在規範的公共執行緒上進行討論，而不是私人渠道、GitHub拉取請求審查或不相關的場所。這確保了每個人都可以關注和貢獻，避免了討論的分裂，並確保其作為PEP審查過程的一部分得到充分考慮。對該指定執行緒的評論、支援、擔憂和其他反饋是指導委員會或PEP-Delegate在審查PEP時將考慮的關鍵部分。

PEP審查與決議

一旦作者完成PEP，他們可以請求PEP編輯進行風格和一致性審查。然而，PEP的內容審查和接受最終由指導委員會負責，該過程透過在作者（和贊助者，如果有）確定PEP已準備好進行最終審查和決議後，開啟一個指導委員會問題正式啟動。

為了在特定情況下加速流程（例如，當某項更改顯然有益且已準備好被接受，但PEP尚未正式提交審查時），指導委員會也可以啟動PEP審查，首先通知PEP作者並給予他們修改的機會。

PEP批准的最終權威是指導委員會。然而，每當提出新的PEP時，任何認為自己有足夠經驗對該PEP做出最終決定的核心開發者都可以透過通知指導委員會其意圖來提出擔任其PEP-Delegate。如果指導委員會批准其提議，PEP-Delegate將擁有批准或拒絕該PEP的權力。對於與Python型別系統相關的PEP，型別委員會（PEP 729）向指導委員會提供建議。要請求此類建議，請在型別委員會問題追蹤器上開啟一個問題。

在指導委員會治理模型下，“PEP-Delegate”一詞用於PEP的指定決策者，其記錄在PEP標題的“PEP-Delegate”欄位中。“BDFL-Delegate”是PEP-Delegate的已棄用別名，是Python由BDFL領導時期的歷史遺留。任何遺留的“BDFL-Delegate”引用都應視為等同於“PEP-Delegate”。

自薦擔任PEP-Delegate的個人必須通知相關的作者和（如果存在）PEP的贊助者，並向指導委員會提交請求（可以透過新問題完成）。承擔此責任的人員可以隨時尋求指導委員會的額外指導，並應考慮其他核心開發者的建議和觀點。

指導委員會通常會預設批准此類自薦，但可能會選擇拒絕。指導委員會拒絕自薦為PEP-Delegate的可能原因包括但不限於：感知到潛在的利益衝突（例如，與PEP提交者在同一組織工作），或者僅僅認為另一位潛在的PEP-Delegate更合適。如果核心開發者（或其他社群成員）對某個給定PEP的PEP-Delegate的適宜性有疑問，他們可以要求指導委員會審查該授權。

如果沒有志願者站出來，那麼指導委員會將聯絡具有相關專業知識的核心開發者（以及可能其他Python社群成員），以嘗試找到願意擔任該PEP的PEP-Delegate的候選人。如果找不到合適的候選人，那麼該PEP將被標記為“延期”，直到有合適的候選人出現。

先前任命的PEP-Delegate可以選擇辭職，或被委員會要求辭職，在這種情況下，將以與新PEP相同的方式任命新的PEP-Delegate（包括如果找不到合適的替代者，則將PEP延期）。如果PEP-Delegate被要求辭職，這將推翻之前對PEP的任何接受或拒絕，並且該PEP將恢復為草案狀態。

當設立此類常設授權時，指導委員會將維護足夠的公共記錄，以使後續委員會、核心開發者以及更廣泛的Python社群能夠了解當前存在的授權、設立原因以及可能不再需要授權的情況。

要被接受，PEP必須滿足某些最低標準。它必須是對所提議增強功能的清晰完整的描述。增強功能必須代表淨改進。所提議的實現（如果適用）必須穩健，並且不得過度複雜化直譯器。最後，所提議的增強功能必須“符合Python風格”才能被指導委員會接受。（然而，“符合Python風格”是一個不精確的術語；它可以被定義為指導委員會可以接受的任何東西。這個邏輯是有意迴圈的。）有關標準庫模組接受標準的詳細資訊，請參閱PEP 2。

除非指導委員會另行批准，否則PEP決議的公告將釋出到Python Discourse上的PEPs類別。

一旦PEP被接受，參考實現必須完成。當參考實現完成並併入主原始碼倉庫時，其狀態將更改為“Final”。

為了在語言特性或標準庫API長期穩定之前收集額外的設計和介面反饋，PEP也可以被標記為“Provisional”。這縮寫為“Provisionally Accepted”，表示該提案已被接受並納入參考實現，但在完整設計被視為“Final”之前，還需要額外的使用者反饋。與常規接受的PEP不同，臨時接受的PEP即使在相關更改已包含在Python版本中之後，仍可能被拒絕或撤回。

在可能的情況下，最好縮小提案範圍，以避免依賴“臨時”狀態（例如，透過將某些功能推遲到後續的PEP），因為這種狀態可能導致更廣泛的Python生態系統中出現版本相容性挑戰。PEP 411提供了關於“臨時”狀態潛在用例的更多細節。

PEP也可以被分配“延期（Deferred）”狀態。當PEP沒有進展時，PEP作者或編輯可以為PEP分配此狀態。一旦PEP被延期，PEP編輯可以將其重新分配為草案狀態。

PEP 也可能被“拒絕”（Rejected）。也許經過一番討論，發現它並非一個好主意。記錄這一事實仍然很重要。“撤回”（Withdrawn）狀態類似——這意味著PEP作者自己決定該PEP實際上是個壞主意，或者接受了競爭提案是一個更好的替代方案。

當一個PEP被接受、拒絕或撤回時，應相應地更新PEP。除了更新狀態欄位外，至少應新增Resolution標題，其中包含指向就PEP做出決定的相關帖子的直接連結。

PEP也可以被不同的PEP取代，使原始的PEP過時。這適用於資訊性PEP，其中API的第2版可以取代第1版。

PEP狀態的可能路徑如下

雖然圖中未顯示，“已接受”的PEP即使在接受後也可能技術上轉變為“已拒絕”或“已撤回”。這僅在實現過程揭示設計中的根本缺陷且在PEP接受前未被發現時才會發生。與臨時PEP不同，這些轉換僅在接受的提案**未**包含在Python版本中時才允許——已釋出的更改必須經過常規的棄用流程（這可能需要一個新的PEP來提供棄用的理由）。

一些資訊性和流程PEP如果從不打算完成，也可能具有“活躍（Active）”狀態。例如PEP 1（本PEP）。

PEP維護

一般來說，PEP在達到“已接受”、“最終”、“已拒絕”或“已取代”狀態後，不再進行實質性修改。一旦達成決議，PEP就被視為歷史文件而非活規範。預期的行為的正式文件應在其他地方維護，例如核心特性的語言參考、標準庫模組的庫參考或打包的PyPA規範。

如果在“臨時”或（經SC批准）“已接受”狀態下的標準跟蹤PEP根據實現經驗和使用者反饋進行更改，應在PEP中註明，以便PEP在標記為“最終”時準確描述其實現。

活躍（資訊性或流程性）PEP可能會隨著時間推移進行更新，以反映開發實踐和其他細節的變化。在這些情況下遵循的具體流程將取決於相關PEP的性質和目的。

偶爾，一個“延期”甚至“撤回”的PEP可能會透過重大更新而復活，但通常最好直接提出一個新的PEP。

一個成功的PEP應該包含什麼？

每個PEP應包含以下部分：

前言 – RFC 2822 風格的標題，包含關於PEP的元資料，包括PEP編號、簡短的描述性標題（最多44個字元）、作者姓名以及可選的聯絡資訊等。
摘要 – 對所解決技術問題的簡短（約200字）描述。
動機 – 動機對於希望改變Python語言、庫或生態系統的PEP至關重要。它應清楚地解釋為什麼現有語言規範不足以解決PEP解決的問題。這可以包括從Python生態系統中的重要專案收集對PEP的支援文件。缺乏充分動機的PEP提交可能會被拒絕。
理由 – 理由透過描述做出特定設計決策的原因來充實規範。它應該描述考慮過的替代設計和相關工作，例如該功能在其他語言中是如何支援的。
該理由應提供社群內部共識的證據，並討論在討論過程中提出的重要異議或擔憂。
規範 – 技術規範應描述任何新語言特性的語法和語義。規範應足夠詳細，以允許至少在當前主要Python平臺（CPython、Jython、IronPython、PyPy）上進行競爭性、可互操作的實現。
向後相容性 – 所有引入向後不相容性的PEP都必須包含一個描述這些不相容性及其嚴重程度的部分。PEP必須解釋作者如何提議處理這些不相容性。缺乏充分的向後相容性論述的PEP提交可能會被直接拒絕。
安全影響 – 如果PEP存在安全隱患，應明確寫出這些隱患，以確保PEP的審閱者知曉。
如何教授 – 對於新增新功能或更改語言行為的PEP，包含一個關於如何教導新老使用者將PEP應用於其工作的章節會很有幫助。
本節可包括關鍵點和建議的文件更改，這些將幫助使用者採用新功能或將其程式碼遷移以使用語言更改。
參考實現 – 參考實現必須在任何PEP獲得“最終”狀態之前完成，但不必在PEP被接受之前完成。雖然在編寫程式碼之前就規範和理由達成共識的方法有其優點，但“大致共識和執行程式碼”的原則在解決許多API細節討論時仍然有用。
最終實現必須包含適用於Python語言參考或標準庫參考的測試程式碼和文件。
被拒絕的想法 – 在PEP討論過程中，會提出各種未被接受的想法。這些被拒絕的想法應連同拒絕的原因一併記錄。這既有助於記錄PEP最終版本背後的思考過程，又可以防止人們在後續討論中再次提出相同被拒絕的想法。
從某種意義上說，本節可以看作是“理由”部分的細分，專門關注某些想法最終未被採納的原因。
未解決的問題 – 當PEP處於草案階段時，可能會出現一些需要進一步討論的想法。這些想法應該被記錄下來，以便人們知道它們正在被考慮但尚未有具體的解決方案。這有助於確保PEP準備好考慮所需的所有問題都已完成，並減少人們重複之前的討論。
致謝 – 用於感謝和表彰幫助開發、討論或起草PEP的人員，或用於任何其他目的。本節可用於認可非共同作者的工作貢獻者。
腳註 – PEP中引用的腳註集合，以及列出非內聯超連結目標的地方。
版權/許可 – 每個新的PEP必須置於公共領域和CC0-1.0-Universal的雙重許可之下（請參閱本PEP以獲取示例）。

PEP格式和模板

PEP是使用reStructuredText格式進行UTF-8編碼的文字檔案。reStructuredText允許豐富的標記，但仍然非常易讀，並且能生成美觀且功能齊全的HTML。PEP 12包含說明和PEP模板。

PEP文字檔案會自動轉換為HTML（透過基於Sphinx的構建系統），以便於線上閱讀。

PEP頭部序言

每個PEP都必須以RFC 2822風格的頭部序言開頭。頭部必須按以下順序出現。標有“*”的頭部是可選的，並將在下面描述。所有其他頭部都是必需的。

  PEP: <pep number>
  Title: <pep title>
  Author: <list of authors' names and optionally, email addrs>
* Sponsor: <name of sponsor>
* PEP-Delegate: <PEP delegate's name>
  Discussions-To: <URL of current canonical discussion thread>
  Status: <Draft | Active | Accepted | Provisional | Deferred | Rejected |
           Withdrawn | Final | Superseded>
  Type: <Standards Track | Informational | Process>
* Topic: <Governance | Packaging | Release | Typing>
* Requires: <pep numbers>
  Created: <date created on, in dd-mmm-yyyy format>
* Python-Version: <version number>
  Post-History: <dates, in dd-mmm-yyyy format,
                 inline-linked to PEP discussion threads>
* Replaces: <pep number>
* Superseded-By: <pep number>
* Resolution: <date in dd-mmm-yyyy format, linked to the acceptance/rejection post>

作者頭列出了PEP所有作者/所有者的姓名，以及可選的電子郵件地址。作者頭值的格式必須是

Random J. User <random@example.com>

如果包含電子郵件地址，則只需

Random J. User

如果未給出地址。大多數PEP作者使用他們的真名，但如果您更喜歡不同的名字並在與PEP相關的討論中始終使用它，請隨意在此處使用。

如果有多位作者，則每位作者應遵循RFC 2822續行約定，各自佔據單獨一行。請注意，PEP中的個人電子郵件地址將進行混淆處理，以防禦垃圾郵件收集器。

Sponsor欄位記錄了哪個開發者（核心開發者，或經指導委員會特別批准的開發者）正在贊助該PEP。如果PEP的作者之一是核心開發者，則無需贊助者，因此應省略此欄位。

PEP-Delegate欄位用於記錄由指導委員會任命的個人，負責對PEP的批准或拒絕做出最終決定。

注意：Resolution 標題僅對標準跟蹤 PEP 必需。它包含一個 URL，該 URL 應指向做出關於 PEP 的宣告（即批准或拒絕）的電子郵件訊息或其他網路資源。

Discussions-To 標題提供了指向 PEP 當前規範討論執行緒的 URL。對於電子郵件列表，這應該是一個直接連結到列表中存檔中該執行緒的連結，而不是僅僅是一個 mailto: 或指向列表本身的超連結。

型別標題指定了PEP的型別：標準跟蹤、資訊性或流程。

可選的Topic標題列出了PEP所屬的特殊主題（如果有）。請參閱主題索引以檢視現有主題。

建立日期（Created）標題記錄了PEP被分配編號的日期，而釋出歷史（Post-History）則用於記錄PEP討論執行緒的日期和相應的URL，前者作為連結文字，後者作為連結目標。兩組日期都應採用dd-mmm-yyyy格式，例如14-Aug-2001。

標準跟蹤 PEP 通常會有一個 Python-Version 標題，指示該功能將在哪個 Python 版本中釋出。沒有 Python-Version 標題的標準跟蹤 PEP 表示互操作性標準將最初透過外部庫和工具支援，然後可能會由後續的 PEP 補充，以將支援新增到標準庫中。資訊性和過程性 PEP 不需要 Python-Version 標題。

PEP可以有一個Requires頭，指示該PEP所依賴的PEP編號。

PEP也可以有一個Superseded-By標題，表明一個PEP已被後續文件取代；其值是取代當前文件的PEP編號。較新的PEP必須有一個Replaces標題，包含它所取代的PEP編號。

對於每個新的PEP，編輯會執行以下操作：

確保該PEP由核心開發者共同撰寫，或由核心開發者贊助，或由指導委員會為此PEP特別批准的贊助者贊助。
閱讀PEP，檢查它是否已準備就緒：健全且完整。這些想法必須在技術上合理，即使它們看起來不太可能被接受。
標題應準確描述內容。
副檔名正確（即.rst）。
確保PEP的所有贊助者或共同作者中，對PEP倉庫具有寫入許可權的人員都已新增到.github/CODEOWNERS中。
快速瀏覽PEP，檢查語言（拼寫、語法、句子結構等）和程式碼風格（示例應符合PEP 7和PEP 8）是否存在明顯缺陷。編輯可以自行糾正問題，但並非必須這樣做（reStructuredText語法由倉庫的CI檢查）。
如果一個專案被描述為受益於或支援PEP，請確保包含來自該專案的一些直接指示，以明確表示支援。這是為了避免PEP在事實上支援基於推測的情況下，意外地將一個專案描繪成支援該PEP。

如果PEP尚未準備就緒，編輯會將其退回給作者進行修改，並附上具體說明。如果reST格式有問題，請要求作者使用PEP 12作為模板並重新提交。

一旦PEP準備好進入倉庫，PEP編輯將

檢查作者是否選擇了有效的PEP編號，如果未選擇則分配一個（幾乎總是下一個可用編號，但有時是特殊/玩笑編號，如666或3141）。
請記住，小於100的數字是元PEP。
檢查作者是否正確標記了PEP的型別（“Standards Track”、“Informational”或“Process”），並將其狀態標記為“Draft”。
確保所有CI構建和 lint 檢查都透過，沒有錯誤，並且渲染的預覽輸出中沒有明顯的問題。
合併新的（或更新的）PEP。
告知作者下一步（開啟討論執行緒並更新PEP，釋出公告等）。

現有 PEP 的更新應作為GitHub 拉取請求提交。

許多PEP由對Python程式碼庫具有寫入許可權的開發者編寫和維護。PEP編輯會監控PEP倉庫的更改，並糾正他們發現的任何結構、語法、拼寫或標記錯誤。

PEP編輯不對PEP作出判斷。他們只負責行政和編輯部分（這通常是一個低工作量的任務）。

資源

版權

本文件置於公共領域或 CC0-1.0-Universal 許可證下，以更寬鬆者為準。

來源：https://github.com/python/peps/blob/main/peps/pep-0001.rst

上次修改時間：2025-08-09 01:23:33 GMT

Python 增強提案