?原文：Infoworld 譯文：開源中國（微信ID：oschina2013）
轉(zhuǎn)載請在文中注明上述信息，其他來源無效
Python 創(chuàng)始人?Guido van Rossum 前段時間宣布脫離 Python 決策層，辭去所謂的 BDFL (終生仁慈的獨裁者) 身份曾引發(fā)熱議，當時他以PEP 572改進提案的爭吵事件為例赡盘，表明其退出緣由。近日 Guido van Rossum 在接受外媒InfoWorld 采訪時缰揪，再次聊到了關于他退出決策層背后的隱情陨享，以及對 Python 開發(fā)流程的看法。
InfoWorld：為什么辭去 BDFL 職務钝腺？
van Rossum：其實抛姑，所謂的終生和獨裁都只是玩笑話。在過去十年的大部分時間里艳狐，我一直有退休的念頭定硝。我自身有一些健康問題，雪上加霜的是我需要無數(shù)次地去告訴社區(qū)的人們該如何做事并保持冷靜毫目，也需要無數(shù)次地去向別人解釋 Python 的語言哲學蔬啡。
壓倒駱駝的最后一根稻草是一個非常有爭議的 Python 改進提案（即PEP 572），在我接受它之后镀虐，他們?nèi)チ讼?Twitter 這樣的社交媒體并說出了一些真正傷害我個人的話語箱蟆。而且說這些事情的實際上都是 Python 的核心開發(fā)者官硝，所以我覺得我們相互之間已不再信任摧阅。
InfoWorld：能否談談 PEP 572?提案的好處以及為何如此具有爭議性？
van Rossum：該提案是關于給 Python 添加表達式內(nèi)賦值的一種語法∨岛耍總而言之抄肖，這是給語言的一個很小的補充，主要是讓人們在需要時窖杀，將賦值放在表達式的中間漓摩。其實許多其他語言也有類似的次要功能，包括我熟悉的 C 和 C ++入客。Java 和 JavaScript 據(jù)我所知也有支持 管毙。它是一種相當小的語法，但在某些情況下桌硫，可以使代碼更容易編寫夭咬，并且通過刪除冗余也更容易閱讀。
很多人認為他們知道 Python 的設計理念是什么铆隘，而這個提議他們覺得沒有遵循 Python 的設計原則卓舵。 該提案引起爭議的另一個原因是提案作者有點自我，前面的幾個版本存在一些嚴重的問題膀钠，導致之后即使是同意其基本理念的人掏湾，也投了反對票。 這是一個輕微的語法變化肿嘲，并不激進融击。
?InfoWorld：該特性將包含在哪個版本的 Python 中？
van Rossum：Python 3.8 雳窟。
?InfoWorld：會有另一個 BDFL 嗎尊浪？ Python 后續(xù)將如何管理？
van Rossum：很遺憾封救，我目前無法告訴你际长。我給了核心開發(fā)團隊一個任務，就是思考后續(xù)的管理模式以及選出相關負責人兴泥。這應該會是一個長期的討論工育，無法立即達成共識。
現(xiàn)在可以說的是搓彻，他們已經(jīng)同意給出提案的截止日期是2018年10月1日如绸。我相信，到2018年11月1日旭贬，他們會選出一個合理的管理提案怔接。到2019年1月1日，他們承諾會完成選舉或任命負責人稀轨。
如果有提案認為需要一個 BDFL 扼脐，那么該提案必須詳細列明細節(jié)，比如說要如何選擇 BDFL ，任命期是多久瓦侮，以及他/她在哪種情況下能被彈劾艰赞。不排除到1月1日，他們真能選出這樣一個人肚吏。
?InfoWorld：您將在 Python 項目中擔任什么角色方妖？
van Rossum：我將成為常規(guī)貢獻者或常規(guī)核心開發(fā)者的角色，偶爾寫一些和審查一些代碼罚攀。我將嘗試專注于指導核心開發(fā)者党觅，尤其是新的核心開發(fā)者，以及女性和少數(shù)群體斋泄，因為核心開發(fā)團隊的多樣性是我的目標之一杯瞻。
InfoWorld：您是否擔心作為 BDFL ，您的離開可能會嚇跑一些 Python 愛好者炫掐？
van Rossum：我不這么認為魁莉。 Python 擁有一個非常健康的社區(qū)，核心團隊也擁有非常強大的能力卒废。如果我認為他們無法克服這一點困難并在未來幾十年內(nèi)繼續(xù)引領語言發(fā)展沛厨，我就不會辭職。我認為這只是一次輕微的打擊摔认，盡管出現(xiàn)了逆皮，但我期待后續(xù)版本的成功以及開發(fā)流程的逐步演變。
?InfoWorld：Python 過去幾年的開發(fā)流程是怎樣的参袱？如何看待其未來發(fā)展电谣？
van Rossum：語言在不斷變化，我們?yōu)樵撜Z言和庫添加了一些新特性抹蚀。過去幾年變化較大的可能是語言的流行度剿牺，直到五年前，Python 還一直感覺自己是一個“小玩家”环壤。
之后隨著數(shù)據(jù)科學的發(fā)展晒来，Python 作為其主要工具出現(xiàn)了令人難以置信的快速發(fā)展。這也導致核心開發(fā)者在決策上有更大的壓力郑现，但是一般情況下湃崩，我們發(fā)布語言的方式非常穩(wěn)定。
我們有發(fā)行管理員（release managers）接箫，主要版本發(fā)行間隔約一年半攒读，Bug 修復版本，由于使用需要辛友，可能會在幾個月到大半年左右薄扁。
我們也有非常穩(wěn)定的 Python 改進提案流程。也許隨著社交媒體的發(fā)展 PEP 的方式有所改變，但總的來說邓梅，除了幾年前從 Mercurial 轉(zhuǎn)向 Git 之外脱盲，PEP 一直是一個非常穩(wěn)定的流程，沒有出現(xiàn)過失誤和問題震放。
