PEP 1 - 目的和方向

作者: Barry Warsaw,Jeremy Hylton,David Goodger,Nick Coghlan
状态: 已被接受或建议很流行(积极) (A)
类型: 流程类 (P)
创建时间: 2001-03-21,2002-07-29,2003-05-03,2012-05-05,2013-04-07

什么是PEP

PEP标准又称为Python改善提案。PEP是向Python社区提供的一种信息文本，有时也用来描述Python的特性以及Python的程序或者环境。一个PEP应该提供Python特性简明的技术规范和原理阐述。

我们想要让PEPs成为一种提供新的Python特性，收集Python社区的议题和记录Python设计的重大决策的主要机制。每个PEP的作者有责任在社区集百家之长，成一家之言。

因为PEPs这种文本文件在版本仓库中是长期被维护的，它们的修订历史是一种Python特性提案的历史记录。这些历史记录可以通过git命令检索，也可以在浏览器中打开on GitHub。

PEP 受众

PEPs的最典型，最主要的受众是Cpython的核心开发人员，指导委员会成员以及其他Python语言规范实现的开发人员。

当然，Python社区的其余部分也可以选择使用这套流程(尤其是PEPs的报告类)，记录需求非常高的API规范和管理协调多个项目之间的复杂的设计协调问题。

PEP 类型

PEP类型有以下三种：

• 标准跟踪类 这类PEP描述了一种新的Python特性或者是Python的实现。它有时也会介绍当前Python版本标准库不支持的，但随后将被未来的Python标准库支持的标准。
• 信息报告类 这类PEP是向Python社区介绍Python的设计议题，提供指导，指明方向等等相关信息。
• 流程类 这类PEP是阐述围绕Python的流程或者流程(或事件)的改变。它类似于标准追踪类的PEPs，但不止只局限在Python，有时也使用Python领域外。它可能提供了一种具体的实现,但是不会向Python的代码库提交。它需要社区的意见一致,它的重要性超过了信息报告类PEPs,社区的成员不能忽视它们。例如: 执行,方向,决策过程的变更,以及Python开发使用的工具或者环境的变更。任何原始的PEP的变化也被认作是流程类PEP。

PEP 运作流程

Python的指导委员会

在这个PEP中多次涉及到的“指导委员会” 或者 “委员会” 是当下在 PEP 13 中所提到的“委员会”成员。这些成员决定了PEPs最后是被接受还是被拒绝。

Python的核心开发人员

在这个PEP中所提到的“核心开发者”是当下活跃在Python核心开发小组成员，名单在PEP 13。

Python的终身仁慈的独裁者(掌舵人)

在之前的PEP的版本中，称呼PEP的决策者，使用是“终身仁慈的独裁者-掌舵人”(BDFL-Delegate) 。这是以前Python管理模式的总结，因为Python语言的创始人Guido van Rossum拥有最终的决定权。(例如社区出现争议的时候，Guido van Rossum拥有拍桌子的权利)而相比之下，现在的最终决定权来自当前活跃的核心开发者。

现在，PEP的掌舵者架空了这位独裁者。

PEP的编辑

PEP的编辑(名词)是管理PEP的工作流程的行政和编辑(动词)的个人。(例如: 确定PEP的编号和改变PEP的状态). 具体细节见PEP编辑的责任和工作内容(此文章的后半部分)

PEP编辑是由现任编辑邀请的，现任编辑通过在GitHub上的@python/prp-editors来联系他们。所有的PEP工作流程都通过GitHubPEP repository交流和提交请求。

从Python的一个想法开始 (PEP的写法)

PEP代表着一个新的Python想法的开始。一个PEP包含着一个关键性的提案或者一个新的想法，这些被集中在PEP，这使得PEPs也变得越来越成功。大多数的改善和补丁不需要通过PEPs这套流程，而是可以之间提交到Python问题追踪处。如果你提交的PEP不够集中或者太宽泛，PEP编辑有拒绝的权力。如果你有异议，可以将你的PEP修改后，让内容更加集中。

每一个PEP都必须有一个作者，他通过下面列出的方式和规定书写PEP。

• 作者在公共场所(例如论坛)，应该合理地引导讨论，并且围绕他的想法在社区形成意见统一。
• 作者应该首先考虑自己的想法符不符合PEP的规定。
• 向Python-idea中的邮件列表中的任何一个邮箱提交自己的想法，或者去Python Discourse的ideas category里，这也是最好的去路。
  还有更专业的站点可以接受，比如static typing中的Typing-SIG 或者讨论封包话题的[Packagingcategory](Packaging category).

公开审查PEP可以更好的为每一位潜在作者节约时间。人们提出了很多改善Python的想法，但因为各不相同的原因而被惨拒。首先在Python社区询问，看自己是想法是否之前被提出过，是否被拒绝过，可以防止花费太多的时间在会被拒绝的事情上。(在网上搜索不一定总有用)
这也可以确保你的想法是适用于整个社区，而不是你自己。因为有些想法对你而言听起来很棒，但是对Python领域内的其他大多数人而言却不一定。

当PEP的作者向Python社区询问自己的想法能否被接受的时候，一份PEP的稿件将会呈现在上述所提到的网站。这给了作者充实自己的PEP,让自己的PEP变的高质量并且解决最初担忧的一个机会。

提交PEP

伴随着上述的讨论交流,工作流程根据PEP提交者身份的不同而变化.
若PEP的联合作者是核心开发人员,他们有责任遵循下面的流程.非核心开发人员,则需要找一位提案人.

正常情况下,一个核心开发者是确人的提案人,但是非核心的提案人或许可以得到委员会成员的支持. GitHub “PEP Editors”团队的成员是被预先批准的提案人.这个提案人的工作是去指导帮助PEP的作者通过PEP流程的逻辑(类似于导师).成为一名提案人不意味着他就不能成为PEP的合著作者或PEP的掌舵者.(不是二者同时是)每一个PEP的提案人被记录在”Sponsor”:这个字段中。

一旦提案人或者核心开发者认为合著的PEP可以发起提案了，那么这个提案应该作为稿件，并且通过GitHub Pull request投递。这个稿件必须使用如下所规定的PEP风格来书写，否则它将会被立刻被退回并且要求修改。(一些小错误将会被编辑直接修正)

提交PEP流程如下:

• 当你是PEP的作者时，你需要forkPEP,并且要创建一个名为pep-9999.rst的文件，文件内容是你的PEP。请使用9999作为你PEP稿件的编号。

• 在设置type时，头部字段请选择“Standards Track”,“Informational”,或者“Process”其中合适的类型。在设置status时，字段要设置为“Draft”。更多的细节，请出门左转至PEP Header Preamble。

• 更新.github/CODEOWNERS ,以便让任何合著者或提案者给你给予对PEP repository访问和写新文件的权限。这确保了未来任何修改文件的请求都将被分配给他们。

• 向你GitHub fock中，push 这个PEP并且提交pull 请求。

• PEP的编辑们将会审查你的PEP的结构、格式以及其他错误。为了方便构建PEP文本的结构和格式，PEP 12提供了一套模板。PEP 12还提供了经常被用在PEPs里的reST，它完整的组成介绍。

• PEP书写标准如下：

  • 你的想法不能听起来很正常，而要有技术意义，否则编辑们不考虑你的想法能否被接受。
  • 标题要和文章内容符合，并且尽量能够概括文章内容。
  • PEP的遣词造句和代码风格(例如: PEP 7和PEP 8)应该前后一致且确定无误。PEP 文本在提交的时候将会自动地被检查reStructuredText格式的正确性，如果不符合reST的格式，PEP将不会被接收。

  编辑们对于初次审稿通常会很宽容，但不要期望通过审稿流程来纠正问题。Note: PEP被接收不保证你PEP内容的没有错误！PEP的正确性是由稿件作者和审稿人保证的，而不是编辑们。

  如果你的PEP不具备被接受的条件，那么编辑则会将你的PEP稿件退回到你手里，并作具体的说明(修改意见)。

• 一旦PEP稿件被接收，编辑将会给你的PEP分配一个编号。
  当审稿全部结束，并且稿件顺利被编辑接收()，