PEP-1学写PEP-参与Python语言的设计

如果你为 Python 写了一篇 PEP, 这篇 PEP 成功的被 Python 指导委员会接受了, 那么以后你在吹牛皮的时候你就可以说我主导了 Python 语言某个特性的设计工作.

                                                          
                                                  -- 跬蟒

我就问你主导 Python 语言特性设计牛不牛皮, 今天我就写一篇文章告诉大家如何去为 Python 设计一篇 PEP, 并且整个 PEP 从一个想法到 Python 语言去实现它的这一套流程:

假设你已经是一个 Python 高手了, 在使用 Python 给过程中你觉得 Python 语言在某方面还不够完善, 你有一个不错的想法可以去改善 Python 这方面的不足, 你打算把你的想法加入到 Python 语言里面, 所以你打算写一篇 PEP, 为 Python 的发展献言建策, 那首先需要做什么呢?

1. 首先你要确保你的想法是个新的想法是个比较大的想法, 是一个由必要去建立一个 PEP 的想法, 也许你发现了 Python 的一些小问题, 但是这些小问题如果提交一个小补丁就可以解决了, 那就没必要提 PEP
2. 当你确定自己的想法很牛 B 之后, 你也不是马上就要提 PEP, 你首先要做的事情是引发社区的讨论, 看看其他人怎么看, 然后自己去实现一下这个想法看是否是可行的, 并且发帖到 python-list@python.org mailing list或者到 python-ideas@python.org mailing list 进行进一步的确定, 看看大家对你的想法是否认同, 如果你能让大多数人都认同, 那你就有戏, 在你发帖之前最好准备一份高质量的 PEP 草稿, 这样的话才会更容易的被接受
3. 总之就是先讨论, 得到大家的认可, 避免后期不必要的撕逼, 然受自己也要做好准备, 最好有个简单的实现, 然后还有个高质量的 PEP 草稿

写 PEP 你不得不知道的几个 Python 社区角色

PEP champion : PEP 拥护者 也就是 PEP 的发起人, 也就是跟大家说我有个非常 XXX 的想法的人

PEP author: PEP 作者 就是写 PEP 的人,PEP 从一个想法到一篇 PEP 草稿, 再到一篇拥有官方 PEP 编号的 PEP 文档, 到后面 PEP 审核通过,PEP 复审出现改动,PEP 被接受这个过程中维护 PEP 文档的人就是 PEP 的作者, 大部分 PEP 作者就是 PEP 拥护者本人

PEP reviewer: 这个角色不是单指某一个人, 一个 PEP 从想法到实现需要经过很多此 review, 每一次参与 review 的人都可以被称作 PEP reviewer

PEP editor: PEP 编辑者 就是对 PEP 进行初步审核的人, 审核通过的 PEP 进入到 github 上面的 PEP 仓库的 master 分支, 进行下一轮的评审

Python Core Developers: Python 核心开发人员 就是开发 Cpython 解释器的那群人, 都是大佬, 都是大佬

Python’s Steering Council: Python 指导委员会 大佬中的大佬, 从Python 核心开发人员 中选择出来的指导 Python 语言开发工作的一群人, 对于 PEP 是否接受有着最终发言权

PEP 的工作流程是这样的:

1. PEP champion 先有一个高质量的 idear(经过讨论分析和理性验证)
2. 你去 github 上面去 fork PEP 仓库
3. 在仓库中创建一个 pep-9999.rst 的文件去把你的 PEP 草稿粘贴进去
4. 确定你的 PEP 的类型,PEP 的状态设为草稿,PEP 头部按照模板写一波
5. 把你的 pep-9999.rst push 到 PEP 仓库
6. 然后 PEP editors 会去审核你的提交
7. 如果审核通过, 这个本来是草稿的 PEP 会拿到一个正规的 PEP 编号, 如果没有审核通过那 PEP editors 会打回去让 PEP author 去修改
8. 如果 PEP 审核通过拿到了 PEP 编号 PEP editor 会把这个新提交的 PEP 合并到 PEP 仓库的 master 分支
9. 如果你的 PEP 的类型是 Standards Track 类, 那你提交的 PEP 还会被发送给 Python-dev list 成员进行再次 review, 确保你的新 PEP 没有坑
10. 有些听起很不错的 PEP 在实现的时候其实是非常蛋疼的, 没做的时候想的挺好, 真正去实现的时候才知道是否靠谱, 最好的情况时你在提交 PEP 的时候你手里就已经有一个这个 PEP 的原型实现了, 所以如果你的 PEP 类型是 Standards Track 类型那你就不仅需要准备设计文档, 你还需要准备一个参考实现, 以此来避免一些不切实际的想法

当然凡事都有例外, 有些 Python 的核心开发者是不会走这个流程的因为他们本身的权限比较大, 他们有直接 push 内容到 PEP 仓库的权限, 所以有时候他们会直接给自己的 PEP 分配一个 PEP 编号 push 进入 PEP 仓库的 master 分支, 当然这并不意味着这个 PEP 就被接受了, 他只是绕过了 PEP editor 的审批而已,PEP 被接受和 PEP 通过审批是完全两码事儿, 只有通过 Python 指导委员会的同意,PEP 计划实现, 才能叫做 PEP 被接受.

如果我写的 PEP 无法审核通过被拒怎么办?

PEP 被拒绝是很正常的事情, 不要灰心, 只要能够坚信自己的 PEP 是真正对 Python 有用的东西, 真正好的 idear, 修改一下继续上就行了, 但是被拒肯定是有原因的, 最主要的原因就是下面几条:

1. 该特性已经存在了
2. 技术上不合理
3. Python 不需要去实现这样的特性, 也就是说伪需求
4. 无法进行后向兼容
5. 不符合 Python 的设计哲学 (Python 设计哲学可以在 Python 交互解释器中输入 import this 获取) 其实在 PEP 的审批阶段可以拿着自己的 PEP idear 去咨询 Python 指导委员会, 因为 PEP 最终会不会被接受其实是由 Python 指导委员会所决定的, 所以如果真的想要自己的 PEP 被接受, 做好提前的沟通还是非常有必要的
6. 奥对了还有一个蛋疼的要求, 就是你的 PEP 草稿必须带着至少一名 Python 核心开发人员一起写, 或者有一个 Python 核心开发人员指导你写, 或者有一个经过 Python 指导委员会批准的非 Python 核心开发人员一起写, 反正就是需要有一个能够被 Python 指导委员会所信任的人参与了你的 PEP 设计, 如果没能满足这个条件 PEP editor 有权直接驳回你的 PEP 草稿

PEP 的复审和决定机制

一篇 PEP 是否最终被接受并且决定去实现是需要经过层层复审的, 反正要经过很麻烦了一个流程, 下面有个 Python 官方画的简单流程图:

但是实际情况比较复杂, 有时候不会按照这个流程图来, 但是这个流程图给人们提供了一个比较清晰的 PEP 工作流的概览

PEP 格式和模板

这年头写啥文档没个模板真不行,PEP 也是文档, 所以模板搞起来:

1. 首先 PEP 是 UTF- 8 编码的 rst 文件, 首先你需要去指导 rst 文件的格式, 如果 rst 的语法格式你已经会了, 那你就可以阅读官方的PEP 12--Sample reStructuredText PEP Template, 没错 PEP12 是介绍 rst 格式 PEP 模板的 PEP(有点绕), 为什么要用 rst 格式? 官方给出的解释是 容易转成 html 进行在线发布和阅读
2. 每一篇 PEP 必须有一个标准的 PEP 头部, 如下所示, 带 号是可写可不写的, 不带 号的是必须要写的, 记住写 PEP 头的时候, 头的各个字段的顺序, 必须按照下图的内容去写, 先后顺序不能乱

写道这里就讲的差不多了, 但是其实 PEP 的书写还有很多的内容比如:

1. 如何判断 PEP 是不是一个成功的 PEP
2. PEP 提交之后发现内容有 bug 怎么解决
3. PEP 所有权以及所有权转移问题
4. PEP editor 的详细职责和工作流
5. 等等问题, 我就不写了, 写不动了 …..

想写 PEP 的可以先根据上面流程走一波,
然后等到遇到问题的时候再去查资料吧.

如果感觉本篇内容还不错, 微信的朋友请点个在看, 其他平台的朋友可以 (近距离) 扫描下方的二维码关注我的公众号 早睡蟒 更多优质原创无广告内容等你来看.