在宣傳海報上，Python 之父 Guido van Rossum 在 EuroPython 2015 會議的發(fā)言分為講話稿和現(xiàn)場問答部分，但是他上臺后將全程改為現(xiàn)場問答的形式。他在回答現(xiàn)場觀眾的問題前，首先以自己的幾個問題和答案推動了會議的進程。話題包括 Python 3（以及3.5），為何沒有2.8版本，為什么有這么多開放的bug，Pypy，還有他討厭 Python 的哪些部分。

Django Girls

Van Rossum 自己的***個問題是他如何看待 Django Girls ——前一天演講的主題。他說，這是一次偉大的對話，他熱愛講故事。他的講話中將不會有相關的內(nèi)容，或者任何“漂亮的幻燈片”。當他聽到Ola...或Ola...為這些幻燈片畫了松鼠和獾時，他非常震驚。

他喜歡的另一個方面是他們申明他們不知道他們正在做什么。讓他想起了 25 年前開始寫 python，他也不知道接下來該怎么做，例如，他不知道一門編程語言需要不同角色的社區(qū)。

他也被他們一年時間創(chuàng)造的“強勢品牌”所感染，“我預計 Ola and Ola、Django Girls 將走的很遠。”

Python 版本

轉換方向，他的下一個疑惑是為什么開發(fā)者轉向 python 3。“你為什么不能放棄 python 3？”，他設問自己。但他沒有說人們應該轉移向 python 3，但他也不想他們這樣做，但是確實有許多困難的工作需要花費一些其他的東西。例如這些應用和網(wǎng)站的面貌，python 2.7 現(xiàn)在并沒有死去，而且會有更多安全修復，或許，接下來的五年將會有更加安全的面貌。移植到 python 3 將有許多繁雜的工作，所以為什么要打擾?

[Guido van Rossum]一方面，Python 3是一種要比 Python 2“好得多的語言”。這是一種非常容易教的語言。比如，Django Girls 工作室是完全基于 Python 3 進行開發(fā)的。要說 Django 的開發(fā)者沒有做過基于框架接口的垃圾工作，那從來都是不可能的。這樣一來，使用這種語言（和這種框架）使得***次開發(fā)體驗更加讓人愉快。

隨 著時間推移，Python 將變得越來越好。比方，Python 3.5 中有“很多出色的新的東西”。他說，Python 2 是一種優(yōu)秀的語言并將一如既往地保持著原本的特性，這讓它漸漸地向***的2.7版靠近。要想在核心開發(fā)者所做的所有工作中獲得益處，唯一辦法是轉移到 Python 3 中去。

一個長期存在的問題是，為什么沒有讓 Python 2.8 發(fā)布，盡管 Van Rossum 指出，可能有些風格有些過時的問題。 Python 2.8 不能解決任何人們想要解決的問題。沒有新的特性，這意味著沒有理由讓版本升級，而從 Python 3 開始移植的閘門已經(jīng)打開。那將使得程序既需要移植到 2.8，還需要移植到 3。

Unicode 是一個移植到 3 的大障礙。但是“該適可而止了”。因此 Python 2 正處在一個狀態(tài)中，它沒有得到新的特性。這讓核心的開發(fā)者把精力集中在 Python 3 上，把它做得更好。

他接下來談及了即將在 9 月份完成的 Python3.5。他曾經(jīng)對如此至多的特性無法選擇，舉個例子來說， os.scandir() 帶來的性能優(yōu)化非常的棒，但實際上大部分的用戶并不會注意到。另一部分用戶對新的矩陣乘法運算符將會感到非常開心。像 NumPy 和其他的科學計算包將會開始使用這玩意，這個特性將會比調(diào)用一個函數(shù)來的『自然』多了。

或許他最喜歡的 Python3.5 特性是語法提示 , 也就是他自己做的那個 PEP。為了讓 PEP 接受它，他可下了不少功夫，自己做為自己的裁判，說服自己接受自己的工作，這也有點小奇怪。不過他還是希望還是有人來給幫他做一個獨立的 Code Review，就像 Mark Shannon 曾經(jīng)作為 BDFL 代表做過的事情一樣，他說。

“如果你對這個也不感到意外的話，上一個 PEP 接受的 Python3.5 特性就是他作為興趣研究搞的異步與等待關鍵詞。這個將會提供一個更自然的途徑去寫關于協(xié)程的代碼。”

公開的bug

最近有人問及他關于 python bug 跟蹤里所有公開 bug 的問題。如果你隨便找一個公開的 bug 看，你會發(fā)現(xiàn)這個 bug 可能已經(jīng)打上了補丁，還有一長串的討論，甚至核心的開發(fā)人員也說補丁可以合并進主干了，但是其實 bug 并沒有修復。難道這是一個不靠譜的核心開發(fā)者或者是老好人？那還需要這些補丁做些什么？

他說，這些問題同樣也在一些其他大的工程上存在。諸多 bug 沒有通過正確的方式關閉，導致了對文檔的誤讀，堆積了更多的 bug。而這些 bug 由于硬件或者開發(fā)環(huán)境的不同很難復現(xiàn)。但是這種 bug 沒有補丁。

這里也有一些功能建議的 bug，并附上了補丁，但我們通常會猶豫是否接受這些更改，因為這些關注點沒有什么用處。比如不具有同類語言的一些功能，或者向后兼容。不打破所有的時間很難接受這些補丁。

另外，核心開發(fā)人員自己都有大量的工作，沒有人來分擔合并補丁到 Python 核心代碼的工作。所有如果沒有核心團隊關注的補丁和功能，一般不會插入到合并流程。

在一個公司里，這些東西是有些不同。人們付款給人做一些枯燥乏味的工作，但要是開源的話你必須自愿完成那些不愉快的任務。一些核心開發(fā)者已經(jīng)做這些枯燥乏味的工作太久了，他們希望從這些工作中脫身。一些開放的 bug 在 bug 追蹤器上有很長的歷史，這是有很多原因的。

最終，總是有很多統(tǒng)計效應被忽略。如果你隨機注意到一個 bug，包括已關閉的 bug，你可能會得到一個已關閉的 bug。許多 bug 很快就被關閉，并且 bug 被簡單地修復，類似于那種快速修復。但是，開放的 bug 的平均壽命是隨著項目年齡的增長而線性增長的，他說。

GIL

有些聽眾問到global interpreter lock（GIL），想要更深入了解這個問題，以及這個問題是如何解決的。Van Rossum笑著反問道：“你有多少時間？”他簡要的講述了GIL產(chǎn)生的歷史。在Python誕生后，多核計算機出現(xiàn)了。當線程運行在不同的內(nèi)核中時，兩個或更多的處理器要更新同一個對象便產(chǎn)生了競爭機制，特別在Python垃圾回收處理機制中。

一個合理的解決方案就是給每個對象上鎖，這樣能保護數(shù)據(jù)不被多路存取破壞。但結果導致當沒有鎖的競爭時，上鎖和解鎖操作代價高昂。一些實驗表明，不需要上鎖的單線程程序性能會因此降低2倍。這意味著只有在使用三個或多個線程或內(nèi)核的程序會從中獲益。

因此，GIL 誕生了（盡管這個名字在它被添加到解釋器后很久才出現(xiàn)）。它是一個立刻有效鎖定所有對象的單一鎖，這樣所有對象訪問將排序進行。目前的問題是，10年或15年以后，多核處理器無處不在，人們想要不必進行多重處理就可利用它們（例如，使用獨立的進程而不是線程通信）

他說，如果你當今想要設計一種新語言，要讓它沒有易變的對象，或者有限的易變性。然而，聽眾中傳來“這就不是 Python 了”。Van Rossum 贊成的說：“你說出了我要說的話”。GIL 周圍有很多開發(fā)者不斷的努力，包括 PyPy 軟件事務內(nèi)存（STM），以及 PyParallel。其他開發(fā)者也撞破了腦袋在想解決辦法。如果有人知道有什么辦法能夠移除 GIL 且讓語言保持 Python 特性，Van 和其他人將很樂意聽到。

PyPy

他被問到 PyPy，他是否使用它，是否有一天它會成為默認的解釋器。他不使用 PyPy，但他下載了一下，玩了幾分鐘，他喜歡他看到的東西。他在兩種模式下使用 Python，或寫些小的腳本完成一些事情，他只使用一個已經(jīng)在他系統(tǒng)已經(jīng)內(nèi)置安裝的解釋器，或者做為一個 Dropbox 的工程師將 Python 布署到集群。

Dropbox 集群運行修改過的 Python 2.7，他說，這引起觀眾的笑聲。“我說過，這不是秘密”，他說。因為 PyPy 比較快，Dropbox 的一些部分在使用 PyPy。但公司擔心一些小的不兼容會導致一些不容易追蹤的 bug。“我們已經(jīng)遇到了太多這樣的問題。”

PyPy 證實了你可以比 CPython 更快的執(zhí)行 Python。它同時提供了一個測試平臺，在這個平臺上可以測試像 STM 這樣有意思的創(chuàng)意。但是保守原則讓人們只在需要加快速度時使用 PyPy。這樣做帶來的問題時，當你發(fā)現(xiàn)時，你已經(jīng)在很多機器上部署了以至于很難遷移。因此，這很像遷移到 Python 3 上遇到的問題。

Dropbox 有很多對第三方的依賴，有些甚至不能在它的源代碼上重構。這對那些在生產(chǎn)環(huán)境中使用了成千上萬行 Python 代碼的公司也是同樣的，他發(fā)現(xiàn) Google 也是這樣，要遷移很困難。

總之，PyPy 是一個“非?？岬捻椖?rdquo;。但是它有很多復選框，需要變得更易檢查。他半開玩笑的建議說，或許 PyPy 需要從 DjangoGirls 中租用 Ola and Ola 來創(chuàng)建一個更大的項目社區(qū)。

最喜歡的

[Guido van Rossum]

接下來的 5 個小問題是他喜歡的東西。喜歡的 web 框架？他說他在任何一個框架中只寫一個 web app，他***嘗試的是 Flask。喜歡的測試庫？他主要使用標準庫中的 unittest 和 mock。編輯器？他現(xiàn)在使用 Emacs，但是最開始使用 vi（兩種都得到不同聽眾的喝彩）。他仍然偶爾使用 vi（或 Vim），但是使用 5 分鐘后，他就要花上 15 分鐘重新適應 Emacs。

除 Python 外最喜歡的語言是什么？他過去常常說是 C 語言，但是“有點無聊”。他信賴的人告訴他現(xiàn)代 C++ 是個優(yōu)秀的語言。他喜歡 Go，但是沒有用它編寫任何有意義的東西。當他與設計師交談后，他喜歡從 Python 偷了一堆東西的 Swift 的外表。從語言中抄襲你喜歡的不好的東西并以一堆不合邏輯的特性而告終很容易，但是 Swift 的設計者看起來沒有這樣做。***，喜歡的異常？在更多的歡呼和笑聲中，他輕輕地笑著回答是鍵盤中斷。

他所討厭的

***的問題是他討厭 Python 哪些方面。他馬上回答：“一切與打包發(fā)布有關的事情”?？偸怯信c版本交叉和依賴有關的問題引起“永無止境的混亂”。他害怕同事跑過來問他“一個簡單的 Python 問題”，有一半是某種輸入路徑問題而且沒有什么簡單的解決辦法。

然后，他的時間到了。EuroPython 會議主辦方為每個主講嘉賓提供了一份禮物：一頂巴斯克貝雷帽和一個大手帕。它們出現(xiàn)在 Van Rossum 演講的***