Python 的指导理事会

There are several references in this PEP to the “Steering Council” or “Council”. This refers to the current members of the elected Steering Council described in PEP 13, in their role as the final authorities on whether or not PEPs will be accepted or rejected.

Python 的核心开发者

There are several references in this PEP to “core developers”. This refers to the currently active Python core team members described in PEP 13.

Python 的 BDFL

这个 PEP 的先前版本对 PEP 的决策者使用了头部 “BDFL-Delegate”。这是对 Python 以前的管理模式的一个历史参考，在这个模式中，所有的设计权力最终都来自于 Guido van Rossum，Python 编程语言的最初创造者。相比之下，指导委员会的设计权力来自于他们由目前活跃的核心开发者选举产生。现在，PEP-Delegate 被用来代替 BDFL-Delegate。

PEP 编辑者

PEP 编辑是负责管理 PEP 工作流程的行政和编辑方面的个体（例如，分配 PEP 编号和改变其状态）。 详见 PEP 编辑的职责和工作流程。

PEP editorship is by invitation of the current editors, and they can be contacted by mentioning @python/pep-editors on GitHub. All of the PEP workflow can be conducted via the GitHub PEP repository issues and pull requests.

从 Python 的创意开始

The PEP process begins with a new idea for Python. It is highly recommended that a single PEP contain a single key proposal or new idea; the more focused the PEP, the more successful it tends to be. Most enhancements and bug fixes don’t need a PEP and can be submitted directly to the Python issue tracker. The PEP editors reserve the right to reject PEP proposals if they appear too unfocused or too broad. If in doubt, split your PEP into several well-focused ones.

Each PEP must have a champion – someone who writes the PEP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The PEP champion (a.k.a. Author) should first attempt to ascertain whether the idea is PEP-able. Posting to the Ideas category of the Python Discourse is usually the best way to go about this, unless a more specialized venue is appropriate, such as Typing-SIG for static typing or the Packaging category of the Python Discourse for packaging issues.

在写 PEP 之前公开审查一个想法，是为了节省潜在作者的时间。许多改变 Python 的想法已经被提出来了，但由于各种原因被拒绝。首先询问 Python 社区，一个想法是否是原创的，有助于防止在基于先前的讨论而保证被拒绝的事情上花费太多时间（在互联网上搜索并不总是能做到这一点）。这也有助于确保这个想法适用于整个社区，而不仅仅是作者本人。仅仅因为一个想法对作者来说听起来不错，并不意味着它对大多数使用 Python 的领域中的大多数人都有效。

Once the champion has asked the Python community as to whether an idea has any chance of acceptance, a draft PEP should be presented to the appropriate venue mentioned above. This gives the author a chance to flesh out the draft PEP to make properly formatted, of high quality, and to address initial concerns about the proposal.

提交 PEP

Following the above initial discussion, the workflow varies based on whether any of the PEP’s co-authors are core developers. If one or more of the PEP’s co-authors are core developers, they are responsible for following the process outlined below. Otherwise (i.e. none of the co-authors are core developers), then the PEP author(s) will need to find a sponsor for the PEP.

理想的情况是，确定一个核心开发者发起人，但经指导委员会批准，也可以选择非核心发起人。GitHub （“PEP编辑”）团队的成员被预先批准成为发起人。发起人的工作是为 PEP 作者提供指导，帮助他们完成 PEP 过程中的后勤工作（有点像导师）。成为发起人并不取消该人以后成为共同作者或 PEP-Delegate（但不能同时成为共同作者）。PEP 的发起人被记录在页眉的 “Sponsor:” 字段中。

Once the sponsor or the core developer(s) co-authoring the PEP deem the PEP ready for submission, the proposal should be submitted as a draft PEP via a GitHub pull request. The draft must be written in PEP style as described below, else it will fail review immediately (although minor errors may be corrected by the editors).

标准 PEP 的工作流程：

• You, the PEP author, fork the PEP repository, and create a file named pep-9999.rst that contains your new PEP. Use “9999” as your draft PEP number.
• 在 “Type:” 头字段中，根据情况输入 “Standards Track”、”Informational” 或 “Process”，在 “Status:” 字段中输入 “Draft”。 详细情况见 PEP Header Preamble
• Update .github/CODEOWNERS such that any co-author(s) or sponsors with write access to the PEP repository are listed for your new file. This ensures any future pull requests changing the file will be assigned to them.
• 推送到你的 GitHub fork 中，并提交一个拉取请求。
• The PEP editors review your PR for structure, formatting, and other errors. For a reST-formatted PEP, PEP 12 is provided as a template. It also provides a complete introduction to reST markup that is used in PEPs. Approval criteria are:
  • 健全而完整。观点必须具有技术意义。编辑们不考虑它们是否似乎有可能被接受”
  • 标题准确描述了内容。
  • The PEP’s language (spelling, grammar, sentence structure, etc.) and code style (examples should match PEP 7 & PEP 8) should be correct and conformant. The PEP text will be automatically checked for correct reStructuredText formatting when the pull request is submitted. PEPs with invalid reST markup will not be approved.

  编辑对这种初步审查一般是相当宽松的，期望通过审查过程纠正问题。注意：批准 PEP 并不保证没有令人尴尬的错误! 正确性是作者和审稿人的责任，而不是编辑的责任。

  如果 PEP 还没有准备好供批准，编辑会把它送回给作者进行修改，并给出具体的指示。

• 一旦获得批准，他们将为你的 PEP 分配一个号码。

Once the review process is complete, and the PEP editors approve it (note that this is not the same as accepting your PEP!), they will squash commit your pull request onto main.

PEP的编辑不会无理地拒绝发表 PEP。拒绝 PEP 状态的原因包括：工作重复、技术上不健全、没有提供适当的动机或解决后向兼容性问题，或者不符合 Python 哲学。在审批阶段可以咨询指导委员会，他们是草案是否为 PEP 的最终仲裁者”

Developers with write access to the PEP repository may claim PEP numbers directly by creating and committing a new PEP. When doing so, the developer must handle the tasks that would normally be taken care of by the PEP editors (see PEP Editor Responsibilities & Workflow). This includes ensuring the initial version meets the expected standards for submitting a PEP. Alternately, even developers should submit PEPs via pull request. When doing so, you are generally expected to handle the process yourself; if you need assistance from PEP editors, mention @python/pep-editors on GitHub.

As updates are necessary, the PEP author can check in new versions if they (or a collaborating developer) have write access to the PEP repository. Getting a PEP number assigned early can be useful for ease of reference, especially when multiple draft PEPs are being considered at the same time.

标准追踪 PEPs 由两部分组成，一个设计文件和一个参考实现。一般来说，建议至少有一个原型实现与 PEP 共同开发，因为原则上听起来不错的想法，在接受实施的考验时，有时会变得不切实际。

Discussing a PEP

As soon as a PEP number has been assigned and the draft PEP is committed to the PEP repository, a discussion thread for the PEP should be created to provide a central place to discuss and review its contents, and the PEP should be updated so that the Discussions-To header links to it.

The PEP authors (or sponsor, if applicable) may select any reasonable venue for the discussion, so long as the the following criteria are met:

• The forum is appropriate to the PEP’s topic.
• The thread is publicly available on the web so that all interested parties can participate.
• The discussion is subject to the Python Community Code of Conduct.
• A direct link to the current discussion thread is provided in the PEP under the Discussions-To header.

The PEPs category of the Python Discourse is the preferred choice for most new PEPs, whereas historically the Python-Dev mailing list was commonly used. Some specialized topics have specific venues, such as Typing-SIG for typing PEPs or the Packaging category on the Python Discourse for packaging PEPs. If the PEP authors are unsure of the best venue, the PEP Sponsor and PEP editors can advise them accordingly.

If a PEP undergoes a significant re-write or other major, substantive changes to its proposed specification, a new thread should typically be created in the chosen venue to solicit additional feedback. If this occurs, the Discussions-To link must be updated and a new Post-History entry added pointing to this new thread.

If it is not chosen as the discussion venue, a brief announcement post should be made to the PEPs category with at least a link to the rendered PEP and the Discussions-To thread when the draft PEP is committed to the repository and if a major-enough change is made to trigger a new thread.

PEP authors are responsible for collecting community feedback on a PEP before submitting it for review. However, to avoid long-winded and open-ended discussions, strategies such as soliciting private or more narrowly-tailored feedback in the early design phase, collaborating with other community members with expertise in the PEP’s subject matter, and picking an appropriately-specialized discussion for the PEP’s topic (if applicable) should be considered. PEP authors should use their discretion here.

Once the PEP is assigned a number and committed to the PEP repository, substantive issues should generally be discussed on the canonical public thread, as opposed to private channels, GitHub pull request reviews or unrelated venues. This ensures everyone can follow and contribute, avoids fragmenting the discussion, and makes sure it is fully considered as part of the PEP review process. Comments, support, concerns and other feedback on this designated thread are a critical part of what the Steering Council or PEP-Delegate will consider when reviewing the PEP.

PEP 审查与解决

Once the authors have completed a PEP, they may request a review for style and consistency from the PEP editors. However, content review and acceptance of the PEP is ultimately the responsibility of the Steering Council, which is formally initiated by opening a Steering Council issue once the authors (and sponsor, if any) determine the PEP is ready for final review and resolution.

为了在选定的情况下加快进程（例如，当一个变化明显有益并准备被接受，但 PEP 还没有正式提交审查），指导委员会也可以启动 PEP 审查，首先通知 PEP 作者，给他们一个机会进行修改。

The final authority for PEP approval is the Steering Council. However, whenever a new PEP is put forward, any core developer who believes they are suitably experienced to make the final decision on that PEP may offer to serve as its PEP-Delegate by notifying the Steering Council of their intent. If the Steering Council approves their offer, the PEP-Delegate will then have the authority to approve or reject that PEP.

The term “PEP-Delegate” is used under the Steering Council governance model for the PEP’s designated decision maker, who is recorded in the “PEP-Delegate” field in the PEP’s header. The term “BDFL-Delegate” is a deprecated alias for PEP-Delegate, a legacy of the time when when Python was led by a BDFL. Any legacy references to “BDFL-Delegate” should be treated as equivalent to “PEP-Delegate”.

An individual offering to nominate themselves as a PEP-Delegate must notify the relevant authors and (when present) the sponsor for the PEP, and submit their request to the Steering Council (which can be done via a new issue ). Those taking on this responsibility are free to seek additional guidance from the Steering Council at any time, and are also expected to take the advice and perspectives of other core developers into account.

The Steering Council will generally approve such self-nominations by default, but may choose to decline them. Possible reasons for the Steering Council declining a self-nomination as PEP-Delegate include, but are not limited to, perceptions of a potential conflict of interest (e.g. working for the same organisation as the PEP submitter), or simply considering another potential PEP-Delegate to be more appropriate. If core developers (or other community members) have concerns regarding the suitability of a PEP-Delegate for any given PEP, they may ask the Steering Council to review the delegation.

如果没有志愿者站出来，那么指导委员会将与具有相关专业知识的核心开发者（以及可能的其他 Python 社区成员）接触，试图确定一个愿意担任该 PEP-Delegate 的候选人。如果找不到合适的人选，那么该 PEP 将被标记为 “Deferred”，直到有合适的人选。

以前任命的 PEP-Delegates 可以选择卸任，或被理事会要求卸任，在这种情况下，将按照任命新的 PEP-Delegates 的方式任命新的 PEP-Delegate（包括如果找不到合适的替代者，则推迟 PEP 的任命）。如果 PEP-Delegate 被要求卸任，这将推翻之前对 PEP 的任何接受或拒绝，并且它将恢复到草案状态。

当这种常设授权到位时，指导委员会将保持足够的公共记录，以使后来的理事会、核心开发商和更广泛的 Python 社区了解目前存在的授权，为什么会有这些授权，以及在什么情况下可能不再需要这些授权。

For a PEP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the interpreter unduly. Finally, a proposed enhancement must be “pythonic” in order to be accepted by the Steering Council. (However, “pythonic” is an imprecise term; it may be defined as whatever is acceptable to the Steering Council. This logic is intentionally circular.) See PEP 2 for standard library module acceptance criteria.

Except where otherwise approved by the Steering Council, pronouncements of PEP resolution will be posted to the PEPs category on the Python Discourse.

一旦一个 PEP 被接受，必须完成参考实现。当参考实现完成并被纳入主源代码库时，状态将被改变为 “Final”。

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

Wherever possible, it is considered preferable to reduce the scope of a proposal to avoid the need to rely on the “Provisional” status (e.g. by deferring some features to later PEPs), as this status can lead to version compatibility challenges in the wider Python ecosystem. PEP 411 provides additional details on potential use cases for the Provisional status.

一个 PEP 也可以被赋予状态：”Deferred”。当 PEP 没有进展时，PEP 的作者或编辑可以给该 PEP 分配这种状态。一旦 PEP 被推迟，PEP 编辑可以将其重新分配为草案状态。

PEP也可以是 “Rejected” 的。也许说来说去，这并不是一个好主意。对这一事实进行记录仍然是很重要的。”Withdrawn” 状态是类似的–它意味着 PEP 作者自己已经决定该 PEP 实际上是一个坏主意，或者已经接受了一个竞争提案是更好的选择。

When a PEP is Accepted, Rejected or Withdrawn, the PEP should be updated accordingly. In addition to updating the Status field, at the very least the Resolution header should be added with a direct link to the relevant post making a decision on the PEP.

PEP 也可以被一个不同的 PEP所取代，使原来的 PEP 过时。这是为信息性 PEP 准备的，即一个 API 的第二版可以取代第一版。

PEP 的状态的可能路径如下：

虽然在图中没有显示，但从技术上讲，”Accepted” 的 PEP 可能会转到 “Rejected” 或 “Withdrawn”，甚至在接受之后。只有在实施过程中发现了设计中的基本缺陷，而在接受 PEP 之前没有注意到时，才会发生这种情况。与临时 PEP 不同的是，只有在被接受的建议没有被包含在 Python 版本中的情况下才允许这些转换–被发布的修改必须通过常规的废弃过程（这可能需要一个新的 PEP 来提供废弃的理由）。

Some Informational and Process PEPs may also have a status of “Active” if they are never meant to be completed. E.g. PEP 1 (this PEP).

PEP 的维护

In general, PEPs are no longer substantially modified after they have reached the Accepted, Final, Rejected or Superseded state. Once resolution is reached, a PEP is considered a historical document rather than a living specification. Formal documentation of the expected behavior should be maintained elsewhere, such as the Language Reference for core features, the Library Reference for standard library modules or the PyPA Specifications for packaging.

If changes based on implementation experience and user feedback are made to Standards track PEPs while in the Provisional or (with SC approval) Accepted state, they should be noted in the PEP, such that the PEP accurately describes the implementation at the point where it is marked Final.

Active (Informational and Process) PEPs may be updated over time to reflect changes to development practices and other details. The precise process followed in these cases will depend on the nature and purpose of the PEP in question.

Occasionally, a Deferred or even a Withdrawn PEP may be resurrected with major updates, but it is often better to just propose a new one.