導致Python之父不幹了的PEP 572討論
作者： Jake Edge
2018-06-20
Python語言峰會
————————
「PEP 572一團糟」是2018年Python語言峰會的主題，該峰會由永遠仁慈的獨裁者Guido van Rossum領導。PEP 572試圖將賦值表達式(或「內聯賦值」)添加到該語言中，但在python開發郵件列表上的多個大議程上，甚至在多次討論python思想之後，都進行了長時間的討論。這些議程常常是有爭議的，而且顯然數量很多，以至於許多人可能就把它們關閉了。在峰會上，Van Rossum概述了這個特性建議，他似乎傾向於接受這個建議，但是他也想討論如何避免將來出現這種議程激增的情況。
賦值
Van Rossum表示，他將努力總結他認為這場爭議的全部內容，不過他警告稱:「或許我們會發現，這是另外一回事。」PEP背後的基本思想是在表達式中執行賦值，這將使編寫一些代碼結構變得更容易。C語言有這個特性，Go也有,但後者使用了一些額外的語法，他覺得這些語法令人討厭。
C語言風格的賦值問題使它會導致這個經典錯誤:
if (x = 0)
...
這在語法上是合法的，但可能不是程序員想要的，因為它將0賦值給x(而不是測試它是否等於0)，而且在if之後的語句塊從不會執行。Van Rossum說，如果您不認為這是一個真正的問題，那麼可以看看yoda風格的條件表達式(原文: Yoda-style conditions)，這些條件表達式顛倒了條件的順序，如果使用=而不是==，那麼它將導致語法錯誤（如果這個問題不重要，Yoda風格為什麼要這樣規定？）:
if (0 = x)
...
Python發誓要以一種不同的方式解決這個問題。正如Tim Peters最近提醒他的那樣，最初的Python只有一個「=」用於賦值和等式測試，但是它使用了不同的語法區別來確保不會出現C語言那樣的問題。Python總是「自豪」自己沒有任何可能產生這個錯誤賦值問題，也不必求助於像Yoda風格這樣的技巧。
在模式匹配中，這類賦值非常有用的一個經典例子是:
PEP中提出的語法將使用一個新的「:=」操作符(可以將其理解為「變成」)，這樣一系列類似於上面的匹配可以替換為:
另一種激勵代碼模式是「半循環」。以前，按行處理文件是很常見的，但現在已經通過使文件對象具有可迭代性解決了這一問題;然而，其他不可迭代的介面仍然受到如下模式的困擾:
或者像這樣:
這兩種方法都可以用一個更清晰簡潔的版本來取代,那就是使用一個賦值表達式:
Van Rossum說他知道自己已經寫過很多半循環的代碼，而且有時沒有寫對。賦值表達式清楚地表達了作者的意圖，而其他兩個表達式則使代碼的讀者更加難以了解是怎麼回事。
另一個例子是列表解析(如列表、字典)。有時程序員為了解析的簡潔性，以至於會兩次調用一個昂貴的函數。他見過這種事情，甚至在優秀程序員的代碼中也見過。
但是Python在沒有這個功能的28年里做得非常好。人們對這個想法的反應各不相同。人們希望找到來自真實代碼的示例，而不是為了證明PEP的合理性而生成的玩具示例。Van Rossum說，Peters和其他人從他們自己的代碼中找到了現實的例子，在這些例子中，這個特性可以使代碼更短，更重要的是，使代碼更清晰。然而，所有這些例子都太長，不適合放在他的幻燈片上。
有爭議的辯論
他認為，爭論如此激烈的原因之一是，人們提出了許多不同的語法變化。以下是議程中討論的可能性部分列表:
可以看到，一些使用了新的操作符，另一些使用了關鍵字，等等。Van Rossum說，他曾試圖推動c風格的賦值，看看它能走多遠，但其他人正在推動他們自己的變體。除此之外，還討論了一些不同的意見，包括需要括弧、運算符的不同優先順序、允許目標不是一個簡單名稱(例如obj.attr或者a[i])，並將構造限制為if、elif和while。
另一個有爭議的問題是在早期混合到PEP中的子-局部作用域的概念。其思想是，隱式作用域只在語句執行期間有效;它可能很有用，但也有一些奇怪的地方。最後，它從PEP中被去掉了。
他說，總的來說，這個想法一直「極具爭議」。一些人認為可讀性更好，另一些人認為可讀性更差。好處是適度的，每個人都有自己喜歡的語法。子-局部作用域添加了其他奇怪的地方，並且需要新的位元組碼來實現它。
PEP還附帶了另一個問題的修復，這個問題在類作用域的理解中是一個「奇怪的角落事件」。他說，這應該從PEP 572中移除，並轉換為它自己的PEP。
在PEP 572上進行了一次投票，但是附加的角落-事件修復是PEP的一部分。這讓投票變得混亂，因為那些想要賦值功能但又不想(或不確定)包含補丁的人沒有辦法投票，需要進行一次新的投票。PEP也過早地轉移到python-dev。
Van Rossum說，Python不是民主團體。但一般人都同意他的決定，「除非我不接受(他們)最喜歡的改變」。
Mark Shannon想知道Python教育大會的與會者是否對這個特性有一些想法。Van Rossum承認一些人說這個特性使得教授Python變得更加困難，但是他並不確定，部分原因是他不知道人們是如何學習Python的。Nick Coghlan說該問題是試圖描述=和:=之間的區別，但是Van Rossum建議老師不要在教學代碼中使用:=。然而，他確實認識到，像Stack Overflow這樣的站點會導致一些新手以可能令人困惑或錯誤的方式複製代碼。
決策
Van Rossum說，這個PEP的更大問題是「我們如何做出決定」。議程中有許多長響應，主要針對該特性。總的來說，「電子郵件太多了」。有許多誤解、離題、解釋，既有對的，也有錯的，等等。部分問題在於，沒有真正的方法來衡量新語言特性的有效性。
最後，他不得不停止閱讀這些帖子，以免自己「發瘋」。Chris Angelico是PEP的作者，他不可能出現在峰會上，但是Van Rossum建議他停止在議程中回應，試圖把事情壓下來。他想知道如何從這種情況中「找出一條出路」。人們開始創建新議程是為了引起那些用太多消息壓制舊議程者的注意。
?ukasz Langa建議「獨裁者決定」; Van Rossum或許應該利用他的角色來阻止這類事情的發生。但如果不這樣，Van Rossum可能就只能像他那樣，推遲並停止關注那些議程。Langa說，正是出於這個原因，他從來沒有遵循過Python的思想。
Van Rossum說，在將它加入到python-dev之前，在python思想討論的基礎上對PEP已經進行了四次修訂;他認為「我們做得對」。Langa想知道是否還有其他類似反應的PEP。靜態類型(也稱為「類型提示」)就是Van Rossum記得的一種。Shannon認為核心開發人員發布的負面帖子沒有PEP 572那麼多。Van Rossum同意這一點，但他也記得幾個核心開發人員也反對輸入提示。
Victor Stinner建議在PEP中總結關於python思想的討論。Van Rossum說，他認為許多回復的人根本沒有讀過PEP中的討論部分。他注意到關於python思想的討論比關於python開發的討論要好，儘管它也有很多充滿激情的帖子。遵循Python思想的人越來越少，Christian Heimes說。Van Rossum想知道，反對派是不是在他介入之後才變得激烈起來的;人們可能沒有認真對待這件事，因為他們認為他不會為了這個而去。
Ned Deily建議用峰會討論的模式來限制討論持續的時間;也許在做出決定前五天。Tcl項目的流程要正式得多，核心開發人員需要對提案進行投票，但他不知道Python項目是否想要這樣做。Van Rossum說，找個人來管理對於PEPs的對話可能會起作用。他熟悉上世紀90年代末的IETF流程，其中有一些就是這樣。他實際上是從IETF借鑒來建立PEP流程的。
但是Barry Warsaw認為PEP 572是一個離群者。由於它改變了語言的語法，人們往往只關注語法，而不理解更深層次的語義問題。他建議，也許除了PEP作者之外，還有一個小團隊可以指導這一類PEP。但最終，人們還是會繼續討論它，直到有人以這樣或那樣的方式做出關於PEP的聲明。
Van Rossum說他通常是避免衝突的，他不喜歡僅僅使用他的BDFL權力來結束一場討論。Angelico在寫這種類型的PEPs方面有些生疏; Van Rossum認為，如果Angelico和Peters沒有參與討論，他很可能就不會一直堅持推動它。Steve Dower說，也許可以將一些PEP發送回去，並請求其他人員與作者合作。
Brett Cannon指出PEP編輯器在轉向python-dev之前並沒有特別仔細地檢查PEP，而主要是確保沒有出現大的文本問題。有一個工作組來確保PEP在進行質量討論時處於正確狀態，這可能會有幫助。Van Rossum說，另一個想法是找一位關於PEPs特性的資深合著者。除了是PEP主題方面的專家，他們還可以利用自己的權威來幫助引導討論。
英文原文：https://lwn.net/Articles/757713/
譯者：浣熊君( ????? )
TAG:Python部落 |