正文
Python - 一些值得阅读的PEP
提示：扫一扫查出行【扫一扫了解最新限行尾号】
复制提示
1- PEP简介
PEP是Python增强提案(Python Enhancement Proposal)的缩写。
社区通过PEP来给Python语言建言献策，每个版本的新特性和变化都是通过PEP提案经过社区决策层讨论、投票决议，最终确定的。
也就是说，PEP是各种增强功能和新特性的技术规格，也是社区指出问题、精确化技术文档、推动Python发展的提案。
一般情况下，可以将PEP视为Python语言的设计文档，包含了技术规范和功能的基本原理说明等。
2- PEP的类型及状态
每个PEP都有对应的类型及状态。
PEP的类型及标志（PEP Types Key）
- S - Standards Track PEP ：跟踪Python中的新特性，就是描述新功能。
- I - Informational PEP ：说明Python中的某一个设计问题，就是指导方针、共识等内容，比如Python之禅、Python新版本的时间表等。
- P - Process PEP ：关于Python的提案，但不针对Python语言本身，就是Python开发中使用的工具、流程或者环境的更改。
PEP的状态及标志（PEP Status Key）
- A - Accepted (Standards Track only) or Active proposal：已接受或活跃的提案
- D - Deferred proposal：被推迟的提案
- F - Final proposal：最终的提案
- P - Provisional proposal：临时的提案
- R - Rejected proposal：被拒绝的提案
- S - Superseded proposal：被取代的提案
- W - Withdrawn proposal：被撤回的提案
示例："PEP 202 -- List Comprehensions"
在页面(https://www.python.org/dev/peps/pep-0202/), 可以看到此PEP的类型及状态信息。
此信息和PEP0（https://www.python.org/dev/peps/）中的对应信息是一致的
3- 阅读PEP
虽然通过阅读PEP可以深入了解Python，但并不意味着需要阅读所有的PEP文件。
比如不需要关注状态为A（Accepted）、D（Deferred）、R（Rejected）、S(Superseded）的PEP，甚至也不需要关注类型I（Informational）。
结合实际学习使用Python的需求，应多关注状态为F（Final）和类型为S（Standards Track）的PEP。
4- 应该知道的几个PEP
PEP 0
Index of Python Enhancement Proposals (PEPs)：所有PEP的索引及分类。
PEP 1
PEP Purpose and Guidelines：PEP的目的和指南。
PEP 257
Docstring Conventions：指导如何规范书写文档说明(Docstring)，提高代码的可维护性。
PEP 404
Python 2.8 Un-release Schedule：关于 Python2.8 版本号不存在的提案，Python2.7将成为Python2的终结版本号，所有的新特新将加入到Python3中。
PEP 8
Style Guide for Python Code：Python代码的规范和应该遵守的编码原则，也称为Python编码风格指南。
函数的风格
- 将 class (类)里边的函数称作 method （方法）
- 给函数命名的时候，与其命名成一个名词，不如命名为一个动词，作为给 class 的一个命令
- 让函数保持简单小巧
类的风格
- class应该使用 “camel case（驼峰式大小写）”
- init 不应该做太多的事情，这会让class变得难以使用
- 其它函数应该使用 “underscore format（下划线隔词）”
- 用一致的方式组织函数的参数
- 不要对全局变量或者来自模组的变量进行重定义或者赋值
- 不要一根筋式地维持风格一致性
- 使用class Name(object)的方式定义class
编码的目的是解决问题，而不是显露风格。
PEP20
The Zen of Python ：在Python命令行终端执行“import this”将显示出关于Python编程的禅学。
>>> import this
The Zen of Python, by Tim Peters Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
>>>
