學寫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的可以先根據上面流程走一波,
然後等到遇到問題的時候再去查資料吧.

如果感覺本篇內容還不錯,微信的朋友請點個在看,其他平臺的朋友可以(近距離)掃描下方的二維碼關注我的公眾號 早睡蟒更多優質原創無廣告內容等你來看.