Python 創始人 Guido van Rossum 前段時間宣佈脫離 Python 決策層，辭去所謂的 BDFL (終生仁慈的獨裁者) 身份曾引發熱議，當時他以 PEP 572 改進提案的爭吵事件為例，表明其退出緣由。近日 Guido van Rossum 在接受外媒 InfoWorld 採訪時，再次聊到了關於他退出決策層背後的隱情，以及對 Python 開發流程的看法。
InfoWorld：為什麼辭去 BDFL 職務？
van Rossum：其實，所謂的終生和獨裁都只是玩笑話。在過去十年的大部分時間裡，我一直有退休的念頭。我自身有一些健康問題，雪上加霜的是我需要無數次地去告訴社區的人們該如何做事並保持冷靜，也需要無數次地去向別人解釋 Python 的語言哲學。
壓倒駱駝的最後一根稻草是一個非常有爭議的 Python 改進提案（即 PEP 572 ），在我接受它之後，他們去了像 Twitter 這樣的社交媒體並說出了一些真正傷害我個人的話語。而且說這些事情的實際上都是 Python 的核心開發者，所以我覺得我們相互之間已不再信任。
InfoWorld：能否談談 PEP 572 提案的好處以及為何如此具有爭議性？
van Rossum：該提案是關於給 Python 添加表達式內賦值的一種語法。總而言之，這是給語言的一個很小的補充，主要是讓人們在需要時，將賦值放在表達式的中間。其實許多其他語言也有類似的次要功能，包括我熟悉的 C 和 C ++。Java 和 JavaScript 據我所知也有支持 。它是一種相當小的語法，但在某些情況下，可以使代碼更容易編寫，並且通過刪除冗餘也更容易閱讀。
很多人認為他們知道 Python 的設計理念是什麼，而這個提議他們覺得沒有遵循 Python 的設計原則。 該提案引起爭議的另一個原因是提案作者有點自我，前面的幾個版本存在一些嚴重的問題，導致之後即使是同意其基本理念的人，也投了反對票。 這是一個輕微的語法變化，並不激進。
InfoWorld：該特性將包含在哪個版本的 Python 中？
van Rossum：Python 3.8 。
InfoWorld：會有另一個 BDFL 嗎？ Python 後續將如何管理？
van Rossum：很遺憾，我目前無法告訴你。我給了核心開發團隊一個任務，就是思考後續的管理模式以及選出相關負責人。這應該會是一個長期的討論，無法立即達成共識。
現在可以說的是，他們已經同意給出提案的截止日期是2018年10月1日。我相信，到2018年11月1日，他們會選出一個合理的管理提案。到2019年1月1日，他們承諾會完成選舉或任命負責人。
如果有提案認為需要一個 BDFL ，那麼該提案必須詳細列明細節，比如說要如何選擇 BDFL ，任命期是多久，以及他/她在哪種情況下能被彈劾。不排除到1月1日，他們真能選出這樣一個人。
InfoWorld：您將在 Python 項目中擔任什麼角色？
van Rossum：我將成為常規貢獻者或常規核心開發者的角色，偶爾寫一些和審查一些代碼。我將嘗試專注於指導核心開發者，尤其是新的核心開發者，以及女性和少數群體，因為核心開發團隊的多樣性是我的目標之一。
InfoWorld：您是否擔心作為 BDFL ，您的離開可能會嚇跑一些 Python 愛好者？
van Rossum：我不這麼認為。 Python 擁有一個非常健康的社區，核心團隊也擁有非常強大的能力。如果我認為他們無法克服這一點困難並在未來幾十年內繼續引領語言發展，我就不會辭職。我認為這只是一次輕微的打擊，儘管出現了，但我期待後續版本的成功以及開發流程的逐步演變。
InfoWorld：Python 過去幾年的開發流程是怎樣的？如何看待其未來發展？
van Rossum：語言在不斷變化，我們為該語言和庫添加了一些新特性。過去幾年變化較大的可能是語言的流行度，直到五年前，Python 還一直感覺自己是一個“小玩家”。
之後隨著數據科學的發展，Python 作為其主要工具出現了令人難以置信的快速發展。這也導致核心開發者在決策上有更大的壓力，但是一般情況下，我們發佈語言的方式非常穩定。
我們有發行管理員（release managers），主要版本發行間隔約一年半，Bug 修復版本，由於使用需要，可能會在幾個月到大半年左右。
我們也有非常穩定的 Python 改進提案流程。也許隨著社交媒體的發展 PEP 的方式有所改變，但總的來說，除了幾年前從 Mercurial 轉向 Git 之外，PEP 一直是一個非常穩定的流程，沒有出現過失誤和問題。
文末知識點摘要：Python類中的方法是如何工作的
在OO(面向對象)編程中，類中的方法有多種形式：實例方法、靜態方法、類方法、甚至還可以有抽象方法，本文來說說實例方法在Python中是如何工作的，後面再來談其他方法。
先來定義一個最簡單類：
class Person:
def __init__(self, name):
self.name = name
def eat(self):
print(self) # <__main__.person object="" at="">
print(type(self)) #
print(self.name + " is eating")
這裡的 eat 就是一個實例方法，跟普通函數差不多，唯一的不同是必須指定一個參數 self，儘管名字可以任意命名，但約定俗成的叫 self，self 是什麼？它代表Person類的實例對象，就像Java中的this一樣，看下面的測試代碼
p = Person("zhangsan")
p.eat()
p與self指向同一個實例對象
那麼可不可以通過類直接調用呢？不行！
Person.eat()
TypeError: eat() missing 1 required positional argument: 'self'
那為什麼通過實例p調用eat方法不需要傳遞self參數呢？這個就要從函數與方法的區別說起。來看看下面的代碼：
print(Person.eat)
print(p.eat)
# 輸出
>
前者是函數，後者是方法，有人說函數定義在類外面，方法定義在類裡面，顯示這種說法不全面，那麼他們的區別在哪裡？
首先方法是與某個對象相關聯的，而函數則不是，p.eat 就是一個綁定了實例對象的方法，函數的所有參數都需要顯示地傳遞，而方法中的數據是隱式傳遞的。Person.eat是函數，參數要顯示地傳遞，Person.eat(p)
而方法因為綁定了實例對象，所以他調用的時候無需再傳遞實例對象了，直接調用p.eat()就可以了，self參數Python會自動傳遞過去，如果重複傳遞會報錯。
p.eat(p)
TypeError: eat() takes 1 positional argument but 2 were given
所以，本質上
p.eat() 等價於 Person.eat(p)
那麼對於實例方法，self 參數從語言設計的角度來說，是不是可以去掉呢，這個問題 Python 之父 Guido van Rossum 撰文解釋過這件事，理由是 “Explicit is better than implicit”
本篇文章分享到此結束，部分素材來源網絡，如有侵權，請聯繫刪除，希望本次分享對正在學習Python的你有所幫助。
閱讀更多 菜鳥學Python 的文章
