「pep」Python中10个必读的PEP提案

pep

640?wx_fmt=jpeg

题图：Photo by Dan Aragón on Unsplash

PEP 是 Python 增强提案(Python Enhancement Proposal)的缩写。社区通过PEP来给 Python 语言建言献策，每个版本你所看到的新特性和一些变化都是通过PEP提案经过社区决策层讨论、投票决议，最终才有我们看到的功能。

0、PEP8

如果你还不知道PEP8是什么，可能还算不上一位合格的Python 程序员，PEP8是每个Python程序员必读的提案，Python虽然以简洁地的语法著称，但是并不意味着你就一定能写出简洁优雅的代码，PEP8风格指南定义了编写 Python 代码的规范和应该遵守的编码原则，我们在在编写代码的过程中都应该按照此规范约束我们的代码。每个开发者都应该多读几遍，做到了然于心。网上有各种版本的中译版，可选择性参考阅读。

有个通用的约定应该是可维护的、清晰可懂的、满足一致性的，同时也应该是好的编程习惯的基础。它不会违背你的意愿来强制要求你遵循那些规则。这就是Python!” — Tim Peter

地址：https://www.python.org/dev/peps/pep-0008/

1、PEP257

除了PEP8，还有PEP257是编写可维护代码的一份提案，指导程序员如何规范书写文档说明(Docstring) 的提案。我们知道Python是动态语言，动态语言的优点是代码简洁，但是缺乏约束性，所以很多时候需要通过文档说明来表达代码，提高代码的可维护性。

地址：https://www.python.org/dev/peps/pep-0257/

中译版：https://my.oschina.net/LuCastiel/blog/1552148

2、PEP20

说到Python里面隐藏的彩蛋，PEP20算得上一个，在Python终端导入this模块，有二十条（其实是19条）关于Python编程的禅学，还不看过的可以在Python命令行输入 import this 试试，讽刺的是，this 模块的源代码晦涩难懂，这也是从作者从侧面来说明代码可读的重要性。

地址： https://www.python.org/dev/peps/pep-0020/

640?wx_fmt=png

3、PEP 557

PEP 557 是最近3.7中加入的新特性，叫做数据类（data class），此举也是让程序员写更少的代码，以前定义一个类，如果该类有很多属性的话，初始化时敲键盘手酸，比如以前一个类：

class RegularCard
    def __init__(self, rank, suit):
        self.rank = rank
        self.suit = suit

    def __repr__(self):
        return (f'{self.__class__.__name__}'
                f'(rank={self.rank!r}, suit={self.suit!r})')

    def __eq__(self, other):
        if other.__class__ is not self.__class__:
            return NotImplemented
        return (self.rank, self.suit) == (other.rank, other.suit)

那些魔术方法你全部要手动实现，现在不要了，你只要在类上面加一个装饰器@dataclass

from dataclasses import dataclass
@dataclass
class DataClassCard:
   rank: str   suit: str

它和上面的代码段是完全等价的，默认帮你实现了__init__等所有魔术方法。

地址：https://www.python.org/dev/peps/pep-0557/

4、 PEP 435

枚举在Python2中被认为是一个没用的东西，打脸的是社区觉得枚举还是有存在的必要，于是 PEP 435 就专门添加了一种枚举类型，话说，在现代编程中，没有枚举真的不能称之为一门完整的语言。

>>> from enum import Enum
>>> class color(Enum):
...     red = 1
...     green = 2...     blue = 3

地址：https://www.python.org/dev/peps/pep-0435/

5、 PEP 3156

PEP 3156 是Python 3.4 中引入异步I/O框架asyncio 的一个提案，提供了基于协程做异步I/O编写单线程并发代码的基础设施。随后在PEP492 中引入了 async/await语法以及 PEP380中的yield from 语法，自此，Python有了原生的协程支持，不再依赖外部第三方库。

地址：https://www.python.org/dev/peps/pep-3156/

6、 PEP 484

Python是一门动态语言，所谓动态类型语言是指我们在定义变量，返回返回值的时候无需指定类型，解析器在运行的时候会自动判断其类型，某种程度上让代码变得更简洁，与此同时，带来的副作用就是在多人合作，bug定位和代码可读性等方面的不方面，所以前面介绍的 PEP257 就是通过文档来规范代码，但是文档是非强制性的，你不写对代码的运行一点影响也没有，所以 PEP 484 （Python3.5 引入）提出了从代码层面上加入了静态语言的部分特性—-类型提示（Type Hints），你现在可以在函数、方法、类的参数和返回值声明其类型。与之类似还有PEP526，不过是关于它是用来给变量指定类型的。

def greeting(name: str) -> str:   return "Hello, {}!".format(name)

现在你会明白，java作为静态语言的优势了吧。

地址：https://www.python.org/dev/peps/pep-0484/

7、PEP 572

PEP 572 是关于表达式赋值的提案，语法是这样的：

while chunk := file.read(8192):  process(chunk)

该提案在社区争议性比较大，就是因为这个提案让 Python 之父愤然退出 Python 核心决策层，因为这个提案与社区其他成员产生了比较大的分歧。虽然Python之父不再是 BDFL，但是该提案最终还是被纳入到 Python3.8 中。

地址：https://www.python.org/dev/peps/pep-0572/

8、PEP 404

PEP 404 正如其名，一个关于 Python2.8 版本号不存在的提案，Python之父曾说过，如果Python3要兼容Python2，可能这个项目已经失败了，因为Python2有太多的历史包袱，所以Python2.7将成为Python2的终结版本号，所有的新特新将加入到Python3中。

地址：https://www.python.org/dev/peps/pep-0404/

9、 PEP 0

说到必看的 PEP，可能远不止我上面列的这些，于是有一个专门的PEP是用来索引所有PEP的集合。

地址：https://www.python.org/dev/peps/pep-0000/

还有哪些PEP是你值得一读的？欢迎留言、点赞、转发

640?

关注公众号

每天让自己变得更厉害一点点

Python中10个必读的PEP提案

pep