如何用通俗易懂的語言解釋《Flask 框架作者希望看到的 Python》到底在說什麼？
原文：Flask 框架作者希望看到的 Python
Python 真的有這種「最大的設計錯誤」嗎？難道 Python 設計者看不到？「槽(slots)系統」真的很糟糕嗎？
作者吐槽了Python語言與CPython解釋器結合得過於緊密。甚至有時候CPython解釋器的某些實現成為了語言的一部分。
雖說有語言規範，但是大多數情況下，它只是規定了解釋器要做什麼，甚至連這些都沒有規定。
Python的問題在文章的「該死的解釋器」一節有了一個直接的解釋：
解釋器把這些類型結構體直接暴露給Python代碼。
比如，你寫了一個BigInteger類（只是舉例子而已）
class BigInteger(object):
...
def __add__(self, other):
return BigInteger(other.Value + self.Value)
...
然後就重載了operator +。但是規範里並沒有說明這一點，這個__add__函數只是在CPython解釋器里實現了。於是就可以通過re-def來覆蓋__add__函數來模擬運算符重載對吧。這就迫使其他Python實現必須實現__add__函數以保證對這些代碼的兼容性。CPython解釋器從誕生伊始就過多地暴露了實現的細節，以至於這些細節成為了Python的一部分。（比如__開頭的成員不能被外部訪問之類的）
這也就是flask作者所說的讓我感到沮喪的是，這門語言大多數問題都與解釋器的細節有關，很少是語言本身。然而這些解釋器的細節，正在變成語言的一部分，這也是為什麼這一點是很重要的。
所以Python / Ruby這些編程語言基本上都是implement-driven而非specification-driven來設計的。
Ruby有過1.8到1.9的一次蛻變，整體上還算是好的。當然你也會看到其他人在吐槽：Matz"s Ruby Developers Don"t Use RubySpec and It"s Hurting Ruby
我認為作者的意思是，Python現在的發展模式是，公開搜集PEP，然後在現有基礎上根據被採用的PEP打補丁，卻幾乎從來不對早起歷史遺留下的解釋器設計做調整和完善，並且幾乎是針對CPython的。新特性越來越多，語言越來越複雜，老的問題一直沒有改進，並且PSF致力於把一些歷史遺留的爛設計解釋成這是Python的哲學……與此同時，Python語言的文檔其實是CPython的文檔，於是乎其它實現，如Jython、PyPy、IronPython也不得不參照這些個奇怪的設計來做……
他舉的例子，如slots的設計就是完全為了兼容了早期解釋器把內置類型的一些方法而做的，以現在的角度來看完全沒有必要……
再說GIL，如果按照python哲學，PSF說這麼做更便於寫C擴展什麼的，說只需要一個解釋器實體什麼的，明明可以脫離GIL，並且別家也都這麼做了，性能也確實能有很大改善，再說GIL帶來的明顯性能缺陷……沒有任何道理把單解釋器歸到python哲學裡……
大致如此吧……整篇文章的意思就是說：
Python明面上給了你一套標準，背地裡自己老走後門；操蛋的是，寫得很多庫之類的還特么依賴自己的後門兒，就算新來的，比如PyPy想走標準，也走不通了，最後也被迫走了後門；
更操蛋的是，他那個後門，開的也不是很高級，一堆缺陷。
Slot 這一點沒看出來有什麼大不了的槽點，cpython 投機取巧又不是說別的解釋器不能投機取巧了，無非就是語言規範散漫了點，比這更戳死人的槽點多了去了。
私以為，以 flask 那個樣子，作者這種吐槽不用太當真，什麼時候 bottle 作者也開始吐槽了再說吧。
首先，flask做的挺爛的，混亂的測試支持，沒準的卡死問題。
然後，他提到的很多問題是框架設計層面的，比如slot，一般用戶用不到，就算需要類似功能也可以有其他實現。
Python C層面確實很多問題，甚至我懷疑都不能算積重難返，而是故意拖延。Python3在幾年前決定大規模重構，但很多核心問題還是扔在那裡沒動。比如GIL仍然是進程級的，而不是解釋器級的。以當前狀態看，如果有Python4的那天，肯定還是個不兼容的升級。
說說看而已，對正常的Python用戶，這些討論都沒什麼卵用。反正大家又用不上。推薦閱讀：