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編程的禪學。

 1 >>> import this  2 The Zen of Python, by Tim Peters  3 
 4 Beautiful is better than ugly.  5 Explicit is better than implicit.  6 Simple is better than complex.  7 Complex is better than complicated.  8 Flat is better than nested.  9 Sparse is better than dense. 10 Readability counts. 11 Special cases aren't special enough to break the rules.
12 Although practicality beats purity. 13 Errors should never pass silently. 14 Unless explicitly silenced. 15 In the face of ambiguity, refuse the temptation to guess. 16 There should be one-- and preferably only one --obvious way to do it. 17 Although that way may not be obvious at first unless you're Dutch.
18 Now is better than never. 19 Although never is often better than *right* now. 20 If the implementation is hard to explain, it's a bad idea.
21 If the implementation is easy to explain, it may be a good idea. 22 Namespaces are one honking great idea -- let's do more of those!
23 >>>

5- 一些須要瞭解的PEP

• PEP 526 -- Syntax for Variable Annotations：指定變量的類型。
• PEP 484 -- Type Hints ：類型約束（類型提示），能夠在函數、方法、類的參數和返回值聲明其類型。
• PEP 557 -- Data Classes ：數據類特性，在Python3.7中加入。
• PEP 309 -- Partial Function Application ：關於偏函數。
• PEP 318 -- Decorators for Functions and Methods ：關於裝飾器。
• PEP 572 -- Assignment Expressions ：關於表達式賦值的提案，在Python3.8中加入。
• PEP 282 -- A Logging System ：關於Logging標準庫。
• PEP 3101 -- Advanced String Formatting ：字符串格式化。
• PEP 3135 -- New Super ：Python3中的super用法。
• PEP 435 -- Adding an Enum type to the Python standard library ：一種枚舉類型。
• PEP 380 -- Syntax for Delegating to a Subgenerator ：引入「yield from」語法。
• PEP 3156 -- Asynchronous IO Support Rebooted: the "asyncio" Module ：引入異步I/O框架asyncio，提供了基於協程作異步I/O編寫單線程併發代碼的基礎設施。
• PEP 492 -- Coroutines with async and await syntax ：引入async/await語法。
• 。。。。。。