原文：flask 框架作者希望看到的 pythonpython 真的有这种「最大的设计错误」吗？难道 python 设计者看不到？「槽(slots)系统」真的很糟糕吗？回复内容：
作者吐槽了python语言与cpython解释器结合得过于紧密。甚至有时候cpython解释器的某些实现成为了语言的一部分。虽说有语言规范，但是大多数情况下，它只是规定了解释器要做什么，甚至连这些都没有规定。python的问题在文章的“该死的解释器”一节有了一个直接的解释：解释器把这些类型结构体直接暴露给python代码。比如，你写了一个biginteger类（只是举例子而已）
class biginteger(object):
…
def __add__(self, other):
return biginteger(other.value + self.value)
…
我认为作者的意思是，python现在的发展模式是，公开搜集pep，然后在现有基础上根据被采用的pep打补丁，却几乎从来不对早起历史遗留下的解释器设计做调整和完善，并且几乎是针对cpython的。新特性越来越多，语言越来越复杂，老的问题一直没有改进，并且psf致力于把一些历史遗留的烂设计解释成这是python的哲学……与此同时，python语言的文档其实是cpython的文档，于是乎其它实现，如jython、pypy、ironpython也不得不参照这些个奇怪的设计来做……他举的例子，如slots的设计就是完全为了兼容了早期解释器把内置类型的一些方法而做的，以现在的角度来看完全没有必要……再说gil，如果按照python哲学，psf说这么做更便于写c扩展什么的，说只需要一个解释器实体什么的，明明可以脱离gil，并且别家也都这么做了，性能也确实能有很大改善，再说gil带来的明显性能缺陷……没有任何道理把单解释器归到python哲学里……大致如此吧……
所以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明面上给了你一套标准，背地里自己老走后门；操蛋的是，写得很多库之类的还特么依赖自己的后门儿，就算新来的，比如pypy想走标准，也走不通了，最后也被迫走了后门；更操蛋的是，他那个后门，开的也不是很高级，一堆缺陷。
首先，flask做的挺烂的，混乱的测试支持，没准的卡死问题。然后，他提到的很多问题是框架设计层面的，比如slot，一般用户用不到，就算需要类似功能也可以有其他实现。python c层面确实很多问题，甚至我怀疑都不能算积重难返，而是故意拖延。python3在几年前决定大规模重构，但很多核心问题还是扔在那里没动。比如gil仍然是进程级的，而不是解释器级的。以当前状态看，如果有python4的那天，肯定还是个不兼容的升级。说说看而已，对正常的python用户，这些讨论都没什么卵用。反正大家又用不上。
slot 这一点没看出来有什么大不了的槽点，cpython 投机取巧又不是说别的解释器不能投机取巧了，无非就是语言规范散漫了点，比这更戳死人的槽点多了去了。私以为，以 flask 那个样子，作者这种吐槽不用太当真，什么时候 bottle 作者也开始吐槽了再说吧。