Python之父重回決策層，社區治理新方案！

版權聲明：豬哥原創，未經贊成，請勿轉載！ https://blog.csdn.net/u014044812/article/details/88356363

在Guido van Rossum(吉多·範羅蘇姆)卸任BDFL（「終身仁慈獨裁者」）一職半年多以後，Python社區迎來了新的治理新方案：指導委員會模式，而通過投票Guido van Rossum也成爲五大指導委員之一，Python之父Guido重回決策層。

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

事件1、龜叔創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解釋器公開發行。

事件2、龜叔離職

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	# 這個叫賦值語句
if i:
	return i

after：

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

能夠看到新增的賦值表達式使代碼更加簡潔，並且這真的只是一個輕微的語法變化，不知爲什麼會引起如此大的震盪，可能不少人早就對龜叔大佬不服了吧！

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

事件3、新的治理方案

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

因而，Python 社區共提出了 7 種治理方案，分別是 PEP 80十、PEP 80十一、PEP 80十二、PEP 801三、PEP 801四、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

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

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