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。