03.09 Python之父重回決策層，帶領開發者一統江湖！

在Guido van Rossum(吉多·範羅蘇姆)卸任BDFL（“終身仁慈獨裁者”）一職半年多之後，Python社區迎來了新的治理新方案：

指導委員會模式，而經過投票Guido van Rossum也成為五大指導委員之一，Python之父Guido重回決策層。

BDFL：全稱是 Benevolent Dictator For Life(終身仁慈獨裁者)，該位置被賦予絕對的最終決策權，因為龜叔具有PEP的最終決策權，而反觀PHP改進則全部是由社區投票決定，所以被稱為”獨裁者“；而“仁慈“這一詞說明龜叔為人很好，不像linux大佬那樣不服就懟，還回回能贏，哈哈！

事件一、龜叔創Python

Guido von Rossum(以下簡稱：龜叔)是荷蘭人，生於1956年1月31日。1982年，Guido從阿姆斯特丹大學獲得了數學和計算機碩士學位。

龜叔接觸並使用過諸如Pascal、C、 Fortran等語言。這些語言的基本設計原則是讓機器能更快運行，因為早期個人電腦配置極低內存可能就一百多kb，所以早期語言很難能實現什麼內存管理、垃圾自動回收、面向對象等，那會讓你的電腦直接卡死！ 但是到了上世紀90年代，計算機得到了快速的發展，硬件的性能越來越好（所以在90年代大量的面嚮對象語言被開發：Python、Visual Basic、Ruby、Java、JavaScript、PHP），所以Guido希望有一種語言，這種語言能夠像C語言那樣，能夠全面調用計算機的功能接口，又可以像shell那樣，可以輕鬆而簡潔的編程。

ABC語言讓龜叔看到希望。ABC是由荷蘭的數學和計算機研究所開發的。20世紀80年代中旬Guido在該研究所工作，並參與到ABC語言的開發。ABC語言以教學為目的。ABC語言希望讓語言變得容易閱讀，容易使用，容易記憶，容易學習，並以此來激發人們學習編程的興趣。

如下面是一段來自Wikipedia的ABC程序，這個程序用於統計文本中出現的詞的總數：

HOW TO RETURN words document:
 PUT {} IN collection
 FOR line IN document:
 FOR word IN split line:
 IF word not.in collection:
 INSERT word IN collection
 RETURN collection

HOW TO用於定義一個函數，PUT是賦值，是不是和Python有很多相識之處。

但是因為硬件性能和語言本身存在的缺陷等原因此語言並沒有流行起來，而1989年聖誕節期間，在阿姆斯特丹，Guido為了打發聖誕節的無趣，決心開發一個新的腳本解釋程序，作為ABC 語言的一種繼承，所以python就被髮明瞭。1991年，第一個用C語言實現的Python解釋器公開發行。

事件二、龜叔離職

2018年7月12日，龜叔通過開發者郵件組宣佈要“移交權力”，促使他作出此決定的導火索是 PEP 572這個改進提案，該提案獲得通過後的三天內龜叔收到了太多的反對意見，龜叔在郵件中有這樣一句話：“我從未想到需要為一個 PEP 費上這麼大的勁，並發現有這麼多人鄙視我的決定”，從這句話可以看出大佬已經心力憔悴了。。。

• 龜叔離職後接受外媒 InfoWorld採訪，其中就聊到這此次退出決策層背後的隱情：https://www.oschina.net/news/98455/guido-van-rossum-resigns
• 龜叔郵件原文鏈接：https://mail.python.org/pipermail/python-committers/2018-July/005664.html，以下翻譯自google翻譯）

PEP：全稱是Python Enhancement Proposal(改進提案)，社區通過PEP來給 Python 語言建言獻策，每個版本你所看到的新特性和一些變化都是通過PEP提案經過社區決策層討論、投票決議，最終才有我們看到的功能。

而這個引發大佬生氣的改進提案PEP 572究竟是個什麼功能呢？

PEP 572：新增了賦值表達式

：：=，這個表達式是不是和賦值符號=很像呢？其實他們的功能都是一樣的：給變量賦值，那區別在哪裡呢？豬哥給大家舉一個簡單的栗子：

befor：

i = 3 + 5\t# 這個叫賦值語句
if i:
\treturn i

after：

if (i: =3 + 5):\t# : =這個叫賦值表達式
\treturn i

可以看到新增的賦值表達式使代碼更加簡潔，而且這真的只是一個輕微的語法變化，不知為何會引發如此大的震盪，可能很多人早就對龜叔大佬不服了吧！

這個改進將在python3.8版本中使用，目前python3.8開發到了alpha 02版本，喜歡嚐鮮的朋友可以去官網下載來玩玩：https://www.python.org/downloads/release/python-380a2/

事件三、新的治理方案

隨著龜叔的撂蹶子，Python的未來之路牽動了萬千開發者的心。沒了首領，Python 今後的發展會怎麼樣？社區將如何運作？誰來領導 Python 這門語言和社區呢？這些問題不得不解決，而用什麼樣的方式解決，這就需要先由社區討論並最終決定。

於是，Python 社區共提出了 7 種治理方案，分別是 PEP 8010、PEP 8011、PEP 8012、PEP 8013、PEP 8014、PEP 8015 與 PEP 8016。這些提案都彙總在 PEP 8000 之下，其中最終勝出者，將決定 Python 未來的發展方向和方式。

2018年12月17號，經過94位核心開發者投票，最終PEP 8016：指導委員會模式當選為新時代的 Python 社區治理方案。

PEP 8016 治理方案採用指導委員會模式，其特點是引導治理的迭代，其中提出了不信任投票，也就是彈劾機制，可將任期內的當權者趕下臺；它嚴格限定了在委員會里，只允許少於 50% 的成員是企業（5 人委員會里最多有 2 個）；並且關注到核心開發者的選舉/淘汰、如何更新治理提案等問題。PEP 8016 也提出了新的 PEP 流程，目前的 PEP 流程是提案人確定 PEP 的選題方向，提案人負責收集與整合來自整個社區的反饋。然後，相關領域的專家們彙總全部討論，並開啟為期 14 天的審查，之後進行社區投票。如果一個 PEP 很有爭議，任何專家成員都可發起動議來拒絕通過它，這需要超過 2/3 的票數。PEP 8016 的 PEP 流程：理事會在必要時可直接地批准/否決 PEP，但最好是設置流程來避免這樣做決策，例如，將決策權委派給團隊或者 BDFL 代表。

這種治理方案有點和聯合國安理會的治理辦法類似，同樣五個委員，同樣具有一票否決權。

投票結果鏈接：https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fe2b74aea628b45

事件四、龜叔當選指導委員

2019 年2 月 4 日，在為期兩週的投票後，Python 社區選出了新治理模式下指導委員會的 5 名成員，在17位候選人中龜叔以得票數第一當選！

我們來看看指導委員會的職能：

• 維護 Python 語言及 CPython 解釋器的質量與穩定性
• 儘可能使做貢獻是便利的、包容的與可持續的
• 鞏固核心團隊與 Python 軟件基金會的關係
• 為 PEP 建立恰當的決策流程
• 為貢獻者與核心團隊尋求共識
• 當其它所有方法都失敗時扮演“最終裁決法庭”的角色

這個治理模式是借鑑自 Django 項目，詳細內容參見 PEP-13。

值得一提的是龜叔是自薦成為候選人的，並且是 17 名候選人中最早自薦或被提名的幾個人之一，說明大佬還是心繫python千千萬萬的開發者；回憶起同樣迴歸的linux之父，我想這些語言之父對自己發明的語言而言肯定會有一種難以割捨的情懷！

Python未來發展之路

看完整個事件的始末，我有種喜憂參半感覺，憂的是python社區治理方案看似從專制走向民主，但誰又能確認這不會淪為新一輪的決策層鬥爭的開始，因為此次事件的根本原因在於核心開發意見不一致造成，而增加決策人員的增加，勢必會造成更大更多的意見不一致，那時決策層是否會產生更大的矛盾？是否會影響python每一年半一次的發佈週期？喜的是龜叔的迴歸我想對千千萬萬的Python開發者們無疑是一個巨大的好消息，有種武俠小說裡幫主歸來的感覺。希望在幫主的帶領下Python一統江湖！

參考：

1.https://www.python.org/dev/peps/

2.https://my.oschina.net/editorial-story/blog/2989027