Python 掌舵委员会

此 PEP 中有几个引用指向“掌舵委员会”或“委员会”。这指的是 PEP 13 中描述的当前当选掌舵委员会成员，他们在决定是否接受或拒绝 PEP 方面拥有最终权威。

Python 核心开发者

此 PEP 中有几个引用指向“核心开发者”。这指的是 PEP 13 中描述的当前活跃的 Python 核心团队成员。

Python 的 BDFL

此 PEP 的早期版本使用“BDFL 代表”作为 PEP 决策者的名称。这是对 Python 以前治理模型的历史参考，在该模型中，所有设计权限最终都来自 Guido van Rossum，他是 Python 编程语言的最初创建者。相比之下，掌舵委员会的设计权限源于他们由当前活跃的核心开发者选举产生。现在，PEP 代表用于代替 BDFL 代表。

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 的想法类别 通常是最好的方法，除非更专业的场所更合适，例如 类型类别（对于静态类型想法）或 打包类别（对于打包想法）。

在着手编写 PEP 之前公开审查想法是为了节省潜在作者的时间。许多关于更改 Python 的想法被提出，但由于各种原因而被拒绝。首先询问 Python 社区某个想法是否原创有助于防止在某些注定会被拒绝的事情上花费太多时间（搜索互联网并不总是有效）。它还有助于确保该想法适用于整个社区，而不仅仅是作者。仅仅因为某个想法对作者听起来不错并不意味着它适用于大多数人在 Python 使用的大多数领域。

一旦负责人询问 Python 社区某个想法是否有被接受的可能性，则应在上面提到的适当场所中展示 PEP 草稿。这使作者有机会充实 PEP 草稿，使其格式正确、质量高，并解决对该提案的最初疑虑。

提交 PEP

在上述初步讨论之后，工作流程会根据 PEP 的任何合著者是否为核心开发者而有所不同。如果 PEP 的一个或多个合著者是核心开发者，则他们有责任遵循下面概述的流程。否则（即，没有合著者是核心开发者），则 PEP 作者需要为 PEP 寻找赞助者。

理想情况下，会确定核心开发者赞助者，但也可以在掌舵委员会批准的情况下选择非核心赞助者。GitHub“PEP 编辑”团队的成员和类型委员会的成员（PEP 729）预先获准成为赞助者。赞助者的工作是为 PEP 作者提供指导，帮助他们完成 PEP 流程的物流工作（有点像导师）。成为赞助者并不会使该人日后无法成为合著者或 PEP 代表（但不能两者兼得）。PEP 的赞助者记录在标题的“赞助者:”字段中。

一旦赞助者或与 PEP 合作的核心开发者认为 PEP 已准备好提交，则应通过 GitHub 拉取请求 提交该提案作为 PEP 草稿。草稿必须以下面描述的 PEP 样式编写，否则将立即失败审查（尽管编辑可能会更正小错误）。

标准 PEP 工作流程如下：

• 您（PEP 作者）分叉 PEP 存储库，并创建一个名为 pep-NNNN.rst 的文件，其中包含您的新 PEP。NNNN 应该是下一个可用的 PEP 编号，未被已发布或正在 PR 中的 PEP 使用。
• 在“PEP:”标题字段中，输入与您的文件名匹配的 PEP 编号作为您的 PEP 草稿编号。
• 在“类型:”标题字段中，输入“标准跟踪”、“信息性”或“流程”（视情况而定），并在“状态:”字段中输入“草稿”。有关完整详细信息，请参阅 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标题下提供了指向当前讨论线程的直接链接。

对于大多数新的 PEP 来说，Python Discourse 的 PEP 类别是首选，而历史上常用的则是Python-Dev 邮件列表。一些专门的主题有特定的场所，例如 Python Discourse 上的类型类别和打包类别分别用于类型和打包 PEP。如果 PEP 作者不确定最佳场所，PEP 赞助商和 PEP 编辑可以相应地为他们提供建议。

如果 PEP 进行了重大的重写或对其提议的规范进行了其他重大、实质性的更改，则通常应在选定的场所创建一个新线程以征求其他反馈。如果发生这种情况，则必须更新Discussions-To链接，并添加一个新的Post-History条目指向此新线程。

如果未将其选为讨论场所，则应在PEP 类别中发布简短的公告帖子，至少包含指向已渲染 PEP 的链接以及Discussions-To线程的链接（当 PEP 草案提交到存储库中时，以及如果进行了重大更改以触发新线程时）。

PEP 作者有责任在提交 PEP 以供审查之前收集社区反馈。但是，为了避免冗长且开放式的讨论，应考虑一些策略，例如在早期设计阶段征求私人或更具针对性的反馈、与具有 PEP 主题专业知识的其他社区成员合作，以及为 PEP 的主题选择一个适当的专业化讨论（如果适用）。PEP 作者应在此处谨慎行事。

一旦 PEP 被分配了一个编号并提交到 PEP 存储库，实质性问题通常应在规范的公共线程上进行讨论，而不是私有渠道、GitHub 拉取请求审查或无关的场所。这确保每个人都可以关注和贡献，避免讨论碎片化，并确保它作为 PEP 审查过程的一部分得到充分考虑。指导委员会或 PEP 代表在审查 PEP 时，将把对此指定线程的评论、支持、关注和其他反馈作为重要组成部分。

PEP 审查与决议

一旦作者完成了 PEP，他们可以请求 PEP 编辑审查其风格和一致性。但是，PEP 的内容审查和接受最终由指导委员会负责，这由在作者（以及赞助商，如果有）确定 PEP 已准备好进行最终审查和决议时打开指导委员会问题正式启动。

为了在选定的情况下加快流程（例如，当更改明显有益且已准备好接受，但 PEP 尚未正式提交审查时），指导委员会也可以启动 PEP 审查，首先通知 PEP 作者并给他们机会进行修订。

PEP 批准的最终权限是指导委员会。但是，每当提出新的 PEP 时，任何认为自己有足够经验做出该 PEP 最终决定的核心开发者都可以通过通知指导委员会他们意图来提议担任其 PEP 代表。如果指导委员会批准他们的提议，则 PEP 代表将有权批准或拒绝该 PEP。对于与 Python 类型系统相关的 PEP，类型委员会（PEP 729）向指导委员会提供建议。要请求此类建议，请在类型委员会问题跟踪器上打开一个问题。

术语“PEP 代表”是在指导委员会治理模型下使用的，用于 PEP 的指定决策者，该决策者记录在 PEP 标题中的“PEP 代表”字段中。术语“BDFL 代表”是 PEP 代表的已弃用别名，是 Python 由BDFL领导时的遗留产物。任何对“BDFL 代表”的遗留引用都应视为等同于“PEP 代表”。

提议自己担任 PEP 代表的个人必须通知相关作者以及（如果存在）PEP 的赞助商，并将他们的请求提交给指导委员会（可以通过新的问题完成）。承担此责任的人员可以随时寻求指导委员会的额外指导，并且还应考虑其他核心开发者的建议和观点。

指导委员会通常会默认批准此类自我提名，但可以选择拒绝它们。指导委员会拒绝作为 PEP 代表的自我提名的可能原因包括但不限于，对潜在利益冲突的看法（例如，与 PEP 提交者在同一组织工作），或者仅仅认为其他潜在的 PEP 代表更合适。如果核心开发者（或其他社区成员）对任何给定 PEP 的 PEP 代表的合适性有任何疑虑，他们可以要求指导委员会审查委托。

如果没有志愿者站出来，则指导委员会将与具有相关专业知识的核心开发者（以及可能的其他 Python 社区成员）联系，试图确定一位愿意担任该 PEP 的 PEP 代表的候选人。如果找不到合适的候选人，则该 PEP 将标记为延迟，直到找到候选人为止。

先前任命的 PEP 代表可以选择辞职，或者被委员会要求辞职，在这种情况下，将以与新 PEP 相同的方式任命新的 PEP 代表（包括如果找不到合适的替代者则延迟 PEP）。如果要求 PEP 代表辞职，这将否决 PEP 之前任何接受或拒绝，并且它将恢复到草稿状态。

当建立此类常设委托时，指导委员会将维护足够的公开记录，以使后续委员会、核心开发者和更广泛的 Python 社区能够了解当前存在的委托、建立这些委托的原因以及它们可能不再需要的具体情况。

为了使 PEP 被接受，它必须满足某些最低标准。它必须是对提议的增强功能的清晰而完整的描述。增强功能必须代表净改进。如果适用，提议的实现必须是可靠的，并且不得过多地使解释器复杂化。最后，提议的增强功能必须是“pythonic”才能被指导委员会接受。（但是，“pythonic”是一个不精确的术语；它可以定义为指导委员会可接受的任何内容。此逻辑是有意循环的。）有关标准库模块接受标准，请参阅PEP 2。

除非指导委员会另有批准，否则 PEP 决议的公告将发布到Python Discourse 上的 PEP 类别。

PEP 被接受后，必须完成参考实现。当参考实现完成并合并到主源代码存储库中时，状态将更改为“最终”。

为了在承诺语言特性或标准库 API 的长期稳定性之前收集额外的设计和接口反馈，PEP 也可以标记为“临时”。这是“临时接受”的简称，表示该提议已被接受纳入参考实现，但在将完整设计视为“最终”之前需要额外的用户反馈。与常规接受的 PEP 不同，即使在相关更改已包含在 Python 版本中之后，临时接受的 PEP 仍可能被拒绝或撤回。

在可能的情况下，建议缩小提案的范围，以避免依赖“临时”（Provisional）状态（例如，将某些功能推迟到以后的 PEP 中），因为这种状态可能导致更广泛的 Python 生态系统中出现版本兼容性问题。PEP 411 提供了有关临时状态潜在用例的更多详细信息。

PEP 也可以被分配“延迟”（Deferred）状态。当 PEP 没有取得进展时，PEP 作者或编辑可以将 PEP 分配此状态。一旦 PEP 被延迟，PEP 编辑可以将其重新分配为草稿状态。

PEP 也可以被“拒绝”（Rejected）。也许在一切都说完之后，它不是一个好主意。记录这一事实仍然很重要。“撤回”（Withdrawn）状态与此类似——这意味着 PEP 作者自己决定 PEP 实际上是一个坏主意，或者已经接受了一个竞争性提案是一个更好的替代方案。

当 PEP 被接受、拒绝或撤回时，应相应地更新 PEP。除了更新“状态”字段外，至少应添加“决议”标题，并提供指向相关决策帖子的直接链接。

PEP 也可以被另一个 PEP 取代，从而使原始 PEP 变得过时。这适用于信息性 PEP，其中 API 的版本 2 可以替换版本 1。

PEP 状态的可能路径如下所示

虽然图中没有显示，“接受”（Accepted）的 PEP 在接受后也可能在技术上转移到“拒绝”或“撤回”状态。这仅在实施过程中发现设计中存在先前未注意到的根本缺陷时才会发生。与临时 PEP 不同，这些转换仅在已接受的提案未包含在 Python 版本中时才允许——已发布的更改必须改为通过常规弃用流程（这可能需要一个新的 PEP 来提供弃用的理由）。

某些信息性 PEP 和流程 PEP 也可能具有“活跃”（Active）状态，如果它们从未打算完成。例如，PEP 1（本 PEP）。

PEP 维护

通常，PEP 在达到“接受”、“最终”、“拒绝”或“取代”状态后，将不再进行实质性修改。一旦达成决议，PEP 将被视为历史文档，而不是动态规范。预期行为的正式文档应在其他地方维护，例如核心功能的语言参考，标准库模块的库参考或打包的PyPA 规范。

如果在临时状态或（经 SC 批准）接受状态下，对标准跟踪 PEP 进行基于实施经验和用户反馈的更改，则应在 PEP 中进行记录，以便 PEP 在标记为最终时准确描述实现。

活跃（信息性和流程）PEP 可能会随着时间的推移而更新，以反映开发实践和其他细节的变化。在这些情况下遵循的具体流程将取决于所讨论的 PEP 的性质和目的。

偶尔，延迟的 PEP 甚至撤回的 PEP 可能会在进行重大更新后复活，但通常最好只是提出一个新的 PEP。