PythonPEP-PEP1

最新推荐文章于 2024-11-05 15:28:12 发布

额...叫啥好呢？

最新推荐文章于 2024-11-05 15:28:12 发布

阅读量61

点赞数

分类专栏： python 文章标签： python

原文链接：https://peps.python.org/pep-0411/

版权

python 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

源于官网PEP-1

PEP 1 – PEP 目的和指南

作者：巴里·华沙、杰里米·海尔顿、大卫·古德格、艾丽莎·科格伦

状态 ..积极

类型：过程

创建：2000 年 6 月 13-

后历史：2001 年 3 月 21 日、2002 年 7 月 29 日、2003 年 5 月 3 日、2012 年 5 月 5 日， 07 四月， 2013

什么是 PEP？

PEP 代表 Python 增强提案。PEP是一种设计向 Python 社区提供信息或描述 Python 或其进程或环境的新功能。PEP的应提供功能的简明技术规范和该功能的基本原理。

我们打算将政治人物会议作为提出重大新建议的主要机制功能，用于收集社区对某个问题的意见，以及记录已进入 Python 的设计决策。PEP的作者负责在社区内建立共识，并记录不同意见。

因为 PEP 在版本化中作为文本文件进行维护存储库，它们的修订历史是功能建议。此历史记录可通过普通 git 获得用于检索旧版本的命令，也可以在 GitHub 上浏览。

PEP受众

PEP 的典型主要受众是 CPython 的核心开发人员参考口译员和他们选出的指导委员会，以及开发人员 Python 语言规范的其他实现。

但是，Python 社区的其他部分也可以选择使用该过程（特别是对于信息性 PEP）来记录预期的 API 约定和管理需要跨部门协作的复杂设计协调问题多个项目。

PEP 类型

PEP有三种类型：

标准跟踪 PEP 描述了新功能或实现对于 Python。它还可以描述一个互操作性标准，该标准将在当前 Python 版本的标准库之外受支持在后续 PEP 将来添加标准库支持之前版本。
信息性 PEP 描述了 Python 设计问题，或者向 Python 社区提供一般指南或信息，但没有提出新功能。信息性 PEP 不会必须代表 Python 社区共识或建议，因此用户和实现者可以自由忽略信息性 PEP 或遵循他们的建议。
流程 PEP 描述了围绕 Python 的流程，或者建议对流程进行更改（或流程中的事件）。工艺 PEP 是与标准跟踪 PEP 类似，但适用于 Python 以外的领域语言本身。他们可能会提出一个实现，但不能 Python 的代码库;它们通常需要社区共识;与信息性 PEP，它们不仅仅是建议和用户通常不能随意忽略它们。示例包括程序、指南、决策过程的变化，以及对 Python 开发中使用的工具或环境的更改。任何元 PEP 也被视为过程 PEP。

PEP 工作流程

Python 指导委员会

本 PEP 中多次提到“指导委员会”或“理事会”。这是指所描述的民选指导委员会的现任成员在 PEP 13 中，他们作为 PEP 是否 PEP 的最终权威将被接受或拒绝。

Python 的核心开发人员

此 PEP 中多次提到“核心开发人员”。这是指 PEP 13 中描述的当前活跃的 Python 核心团队成员。

Python 的 BDFL

此 PEP 的先前版本使用标题“BDFL-Delegate”作为 PEP 决策制造商。这是对 Python 之前治理模型的历史参考，其中所有设计权威最终都来自Guido van Rossum， Python 编程语言的原始创建者。相比之下，转向理事会的设计权来自当前活跃的选举核心开发人员。现在，PEP-Delegate 用于代替 BDFL-Delegate。

PEP 编辑

PEP 编辑是负责管理行政管理的个人以及 PEP 工作流程的编辑方面（例如，分配 PEP 编号和更改其状态）。请参阅 PEP 编辑器的职责和工作流程详。

PEP编辑职位是受当前编辑的邀请，他们可以是通过在 GitHub 上提及联系。所有 PEP 工作流可以通过 GitHub PEP 存储库问题和拉取进行请求。@python/pep-editors

从 Python 的想法开始

PEP 过程始于 Python 的新想法。它高度建议单个 PEP 包含单个关键提案或新的想法;PEP越专注，它往往越成功。大多数增强功能和错误修复不需要 PEP 和可以直接提交到 Python 问题跟踪器。 PEP 编辑保留如果 PEP 提案显得过于不集中或过于突出，则有权拒绝这些提案广泛。如有疑问，请将您的 PEP 分成几个重点突出的 PEP。

每个 PEP 都必须有一个拥护者——使用这种风格编写 PEP 的人和下面描述的格式，引导讨论以适当的方式进行论坛，并试图围绕这个想法建立社区共识。PEP的冠军（又名作者）应该首先尝试确定这个想法是否是 PEP能力。发布到 Python 话语的 Ideas 类别通常是最好的方法，除非有更专业的场地是合适的，例如“打字”类别（用于静态打字想法）或 Python 话语中的打包类别（用于打包想法）。

在编写 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 的文件。应该是下一个已发布或公关中 PEP 未使用的可用 PEP 编号。pep-NNNN.rstNNNN
在“PEP：”标头字段中，输入与您的文件名匹配的 PEP 编号作为您的草稿 PEP 编号。
在“Type：”标题字段中，输入“Standards Track”， “信息”或“过程”（视情况而定），以及“状态：” 字段输入“草稿”。有关完整详细信息，请参阅 PEP 标头前导码。
更新 .github/CODEOWNERS，以便任何合著者或赞助商为您的新文件列出了对 PEP 存储库的写访问权限。这可确保将分配任何将来更改文件的拉取请求对他们来说。
将其推送到 GitHub 分支并提交拉取请求。
PEP 编辑会审查您的 PR 的结构、格式和其他错误。对于 reST 格式的 PEP，PEP 12 作为模板提供。它还提供了对所使用的 reST 标记的完整介绍在 PEP 中。批准标准是：
- 它是健全和完整的。这些想法必须具有技术意义。这编辑们不考虑他们是否有可能被接受。
- 标题准确地描述了内容。
- PEP 的语言（拼写、语法、句子结构等）代码样式（示例应匹配 PEP 7 和 PEP 8）应为正确和符合。将自动检查 PEP 文本提交拉取请求时更正 reStructuredText 格式。具有无效 reST 标记的 PEP 将不被批准。
编辑们通常对这次初步审查相当宽容，期望问题将通过审查过程得到纠正。注意：PEP 的批准并不能保证没有令人尴尬的错误！正确性是作者的责任和审稿人，而不是编辑。

如果 PEP 尚未准备好获得批准，编辑会将其发回作者进行修改，并附有具体说明。
一旦获得批准，他们将为您的 PEP 分配一个号码。

一旦审核过程完成，并且 PEP 编辑批准它（请注意这与接受你的 PEP 不同！），他们会压扁你的将请求拉取到 main。

PEP 编辑不会无理拒绝 PEP 的发布。原因拒绝 PEP 状态包括重复工作、技术不健全、没有提供适当的动机或解决向后兼容性问题，或者没有与 Python 哲学保持一致。可以咨询指导委员会在批准阶段，并且是草案 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 话语的 PEP 类别是大多数新 PEP 的首选，而从历史上看，Python-Dev 邮件列表是常用的。一些专业主题有特定的场地，例如 Python 上的 Typing 类别和 Packaging 类别分别用于打字和打包 PEP 的话语。如果 PEP 作者不确定最佳地点， PEP 赞助商和 PEP 编辑可以相应地向他们提供建议。

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

如果未选择它作为讨论地点，应向 PEP 类别发布简短的公告帖子，至少包含指向呈现的 PEP 和线程的链接当 PEP 草案提交到存储库时如果进行了足够重大的更改以触发新线程。Discussions-To

PEP 作者负责收集社区对 PEP 的反馈在提交审核之前。但是，为了避免啰嗦和开放式讨论，策略，例如征求私人或更多早期设计阶段的狭隘定制反馈，与具有 PEP 专业知识的其他社区成员合作主题，并为应考虑 PEP 的主题（如果适用）。 PEP作者应在此处使用其自由裁量权。

一旦 PEP 被分配了一个编号并提交到 PEP 存储库，实质性问题一般应在规范公众上讨论线程，而不是专用频道、GitHub 拉取请求评论或不相关的场所。这确保了每个人都可以关注和贡献，避免讨论支离破碎，并确保将其充分考虑为 PEP 审查过程的一部分。对此指定主题的评论、支持、疑虑和其他反馈是指导委员会或 PEP 代表的关键部分在审查 PEP 时考虑。

PEP审查和解决

一旦作者完成了 PEP，他们可以要求对来自 PEP 编辑器的风格和一致性。但是，内容审查和对 PEP 的接受最终是指导委员会的责任，由以下机构正式发起一旦作者（和赞助商，如果有的话）打开指导委员会问题确定 PEP 已准备好进行最终审查和解决。

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

PEP 批准的最终机构是指导委员会。但是，每当提出了一个新的 PEP，任何认为自己合适的核心开发人员有经验的人对 PEP 可能提出的作为其 PEP-Delegate 通过通知指导委员会他们的意图。如果指导委员会批准他们的提议，然后，PEP 代表将有权批准或拒绝该 PEP。对于与 Python 类型系统相关的 PEP，打字委员会（PEP 729）向指导委员会提出建议。要请求这样的建议，在打字委员会问题跟踪器上打开一个问题。

“PEP-Delegate”一词用于指导委员会治理模型对于 PEP 的指定决策者，谁记录在 PEP 标题的“PEP-Deleggate”字段中。术语“BDFL-Delegate”是 PEP-Delegates 的已弃用别名，是 Python 由 BDFL 领导的时间。对“BDFL-Delegate”的任何旧引用都应被视为等效于 “PEP代表”。

提出提名自己为 PEP 代表的个人必须通知相关作者和（在场时）PEP 的赞助商，并提交他们向指导委员会提出的要求（可以通过新问题来完成）。承担这一责任的人可以自由地寻求指导委员会随时提供额外指导，也有望提供考虑其他核心开发人员的建议和观点。

指导委员会通常会默认批准此类自我提名，但可能会选择拒绝他们。指导委员会拒绝作为 PEP 代表的自我提名包括但不限于对潜在的利益冲突（例如，与以下机构在同一组织工作 PEP 提交者），或者只是考虑另一个潜在的 PEP 代表更合适。如果核心开发人员（或其他社区成员）有顾虑关于 PEP 代表是否适合任何给定的 PEP，他们可能会问指导委员会审查代表团。

如果没有志愿者挺身而出，那么指导委员会将接近核心开发人员（以及潜在的其他 Python 社区成员）与相关的专业知识，试图确定愿意担任 PEP - 该 PEP 的 Delegate。如果找不到合适的候选人，则 PEP 将被标记为“延迟”，直到可用。

先前任命的 PEP 代表可以选择辞职，或被要求辞职由理事会否决，在这种情况下，将任命一名新的 PEP 代表与新的 PEP 相同的方式（包括在没有合适的情况下推迟 PEP 可以找到替代品）。如果要求 PEP 代表介入下来，这将推翻任何先前对 PEP 的接受或拒绝，并且它将恢复为“草稿”状态。

当这些常设代表团到位时，指导委员会将保持足够的公共记录，以允许随后的理事会，核心开发人员和更广泛的 Python 社区来了解委托目前存在，为什么实施，以及在什么情况下它们可能不再需要。

要接受 PEP，它必须满足某些最低标准。它必须清晰完整地描述拟议的增强功能。增强必须代表净改进。拟议的如果适用，实施必须扎实，不得复杂化口译员不恰当。最后，建议的增强功能必须是 “pythonic”，以便被指导委员会接受。（但是， “Python”是一个不精确的术语;它可以被定义为任何可以接受的东西指导委员会。这种逻辑是有意循环的。有关标准库模块验收标准，请参阅 PEP 2。

除非指导委员会另有批准， PEP 决议的声明将发布到 Python 话语的 PEP 类别中。

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

允许在提交之前收集额外的设计和界面反馈语言功能或标准库 API、PEP 的长期稳定性也可能被标记为“临时”。这是“暂时接受”的缩写，并表明该提案已被接受纳入参考实现，但在完整设计之前需要额外的用户反馈可以被认为是“最终的”。与常规接受的 PEP 不同，临时接受即使在相关更改之后，PEP 仍可能被拒绝或撤回 包含在 Python 版本中。

在可能的情况下，认为最好缩小提案的范围以避免依赖“临时”地位的需要（例如，通过推迟一些功能到以后的 PEP），因为此状态可能会导致版本兼容性更广泛的 Python 生态系统中的挑战。PEP 411 提供了更多详细信息关于临时状态的潜在用例。

PEP 也可以被分配为“延迟”状态。PEP 作者或当没有进展时，编辑可以为 PEP 分配此状态在 PEP 上。推迟 PEP 后，PEP 编辑可以重新分配它到草稿状态。

PEP 也可以被“拒绝”。也许毕竟说了，做了不是一个好主意。对此进行记录仍然很重要事实。“撤回”状态类似 - 这意味着 PEP 作者他们自己已经决定 PEP 实际上是一个坏主意，或者已经接受竞争性提案是更好的选择。

当 PEP 被接受、拒绝或撤回时，应更新 PEP 因此。除了更新“状态”字段外，至少应添加带有直接链接的 Resolution 标头到相关职位，对 PEP 做出决定。

PEP 也可以被不同的 PEP 取代，呈现原始过时。这适用于信息性 PEP，其中版本 2 API 可以替换版本 1。

PEP状态的可能路径如下：

虽然图中未显示，但从技术上讲，“已接受”的 PEP 可能会移动到 “拒绝”或“撤回”，即使在接受后也是如此。这只会在以下情况下发生实施过程揭示了设计中的根本缺陷，这些缺陷是在接受 PEP 之前未被注意到。与临时 PEP 不同，这些仅当已接受的提案未被纳入时，才允许过渡在 Python 版本中 - 发布的更改必须通过常规弃用过程（可能需要一个新的 PEP 提供以下理由弃用）。

某些信息和流程 PEP 也可能具有“活动”状态如果它们永远不会完成。例如，PEP 1（此 PEP）。

PEP维护

一般来说，PEP 在达到 “已接受”、“最终”、“已拒绝”或“已取代”状态。一旦达成决议， PEP 被视为历史文件，而不是活规范。预期行为的正式文档应在其他地方维护，例如核心功能的语言参考、标准库模块的库参考或打包的 PyPA 规范。

如果根据实施经验和用户反馈进行更改标准在临时或（经 SC 批准）接受时跟踪 PEP 状态，它们应该在 PEP 中注明，以便 PEP 准确地描述在标记为 Final 的位置实现。

活动（信息和过程）PEP 可能会随着时间的推移而更新以反映对开发实践和其他细节的更改。精确的工艺在这些情况下遵循将取决于 PEP 的性质和目的有问题。

有时，推迟甚至撤回的 PEP 可能会复活有重大更新，但通常最好只提出一个新的更新。

成功的 PEP 属于什么？

每个 PEP 应包含以下部分/部分：

序言 – RFC 2822 样式标头，包含有关 PEP，包括 PEP 编号、简短的描述性标题（有限最多 44 个字符）、名称和每位作者的联系方式等。
摘要 – 对技术问题的简短（~200 字）描述正在解决。
动机 – 动机对于想要更改 Python 语言、库或生态系统。它应该清楚地解释为什么现有的语言规范是不足以解决 PEP 解决的问题。这可以包括从重要的 PEP 收集对 PEP 的书面支持 Python 生态系统中的项目。PEP 提交没有充分的动机可能会被拒绝。
基本原理 – 基本原理通过以下方式充实规范描述为什么做出特定的设计决策。它应该描述所考虑的替代设计和相关工作，例如，该功能在其他语言中如何得到支持。
理由应提供在《公约》内部达成共识的证据。社区并讨论提出的重要反对意见或疑虑在讨论期间。
规范 – 技术规范应描述任何新语言功能的语法和语义。这规范应该足够详细，以允许竞争，至少当前主要 Python 的可互操作实现平台（CPython、Jython、IronPython、PyPy）。
向后兼容性 – 所有向后引入的 PEP 不兼容必须包括描述这些内容的部分不相容性及其严重性。PEP 必须解释如何作者建议处理这些不兼容性。PEP的没有足够向后兼容性论文的提交可能会被直接拒绝。
安全隐患 – 如果存在相关的安全问题对于 PEP，这些担忧应该明确写出来当然，PEP的审稿人都知道它们。
如何教这个 – 对于添加新功能或更改的 PEP 语言行为，包括一个关于如何教用户，无论是新手还是有经验的用户，如何将 PEP 应用于他们的工作。
本节可能包括要点和推荐的文档有助于用户采用新功能或迁移其使用语言更改的代码。
参考实现 – 参考实现必须是在任何 PEP 被赋予“最终”状态之前完成，但不需要在接受 PEP 之前完成。虽然有优点就规范达成共识的方法和编写代码前的基本原理，原则是“粗略共识” 和运行代码“在解决许多问题时仍然很有用讨论 API 详细信息。
最终实现必须包括测试代码和文档适用于 Python 语言参考或标准库参考。
被拒绝的想法 – 在 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' real names and optionally, email addrs>
* Sponsor: <real name of sponsor>
* PEP-Delegate: <PEP delegate's real 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: <url>

“作者”标题列出了姓名，以及可选的电子邮件地址 PEP 的所有作者/所有者。Author 标头的格式值必须为：

Random J. User <random@example.com>

如果包含电子邮件地址，则只需：

Random J. User

如果未提供地址。

如果有多个作者，则每个作者都应位于单独的行上遵循 RFC 2822 延续行约定。请注意，个人 PEP 中的电子邮件地址将被掩盖，以防御垃圾邮件收割机。

“赞助商”字段记录了哪个开发人员（核心，或以其他方式批准指导委员会）正在赞助 PEP。如果 PEP 的作者之一是核心开发人员，则不需要赞助商，因此应该保留此字段外。

PEP-Delegate 字段用于记录由指导委员会就是否批准或拒绝 PEP。

注意：Standards Track PEP 需要 Resolution 标头只。它包含一个 URL，该 URL 应指向电子邮件或其他网络资源，其中的声明（即批准或拒绝）PEP。

Discussions-To 标头提供当前 PEP 的规范讨论线程。对于电子邮件列表，这应该是指向列表中线程的直接链接存档，而不仅仅是 mailto：或指向列表本身的超链接。

Type 标头指定 PEP 的类型：Standards Track、信息或过程。

可选的 Topic 标头列出了特殊主题（如果有）， PEP属于。有关现有主题，请参阅主题索引。

Created 标头记录为 PEP 分配数字，而 Post-History 用于记录日期和相应的指向 PEP 的 Discussions-To 线程的 URL，前者作为链接文本，后者作为链接目标。两组日期的格式都应相同，例如 .dd-mmm-yyyy14-Aug-2001

标准跟踪 PEP 通常有一个 Python-Version 标头，该标头指示将发布该功能的 Python 版本。没有 Python-Version 标头指示的标准跟踪 PEP 最初将通过以下方式支持的互操作性标准外部库和工具，然后可能由以后的 PEP 补充以添加对标准库的支持。信息和流程 PEP 可以不需要 Python-Version 标头。

PEP 可能有一个 Requires 标头，指示 PEP 编号 PEP取决于。

PEP 还可能具有 Superseded-By 标头，指示 PEP 具有被后来的文件过时了;该值是替换当前文档的 PEP。较新的 PEP 必须具有替换包含它呈现的 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 的类型（“标准跟踪”、“信息”或“流程”），并标记其状态为“草稿”。
确保所有 CI 构建和 lint 检查都顺利通过，并且渲染的预览输出中没有明显的问题。
合并新的（或更新的）PEP。
通知作者后续步骤（打开讨论线程和用它更新 PEP，发布公告等）。

对现有 PEP 的更新应作为 GitHub 拉取请求提交。

许多 PEP 是由具有写入权限的开发人员编写和维护的到 Python 代码库。PEP 编辑器监视 PEP 存储库进行更改，并更正任何结构、语法、拼写或他们看到的标记错误。

PEP 编辑不会对 PEP 做出判断。他们只是做行政和编辑部分（这通常是一项低容量的任务）。

资源：