那些 Python 语言设计上的重大失误

[AndyAO]

python 系统性的限制了代码的灵活执行，不管是 lambda 还是 eval 都只能运行表达式，应用场景十分有限，极大的限制了 python 语言的表现力。

本来能够很容易就写出来的代码，需要绕弯子。

这种限制在当前没有任何站得住脚的合理解释，非要说就只能扯 pythnoic 意识形态大旗。

python 还有个更糟糕的设计是用缩进当做语法，也许在 30 年前能少敲几下键盘，或者让缩进看起来更一致和美观，但是现在的各种 IDE 全都能自动解决这些问题，根本就不需要人操心。

不过这些设计上的问题总会有些争论的，毕竟大家对自己常用的工具都挺有感情的。

设计是好的还是坏的，到现在是否还合时宜，有个更客观的评价标准，就是那个设计是否影响到了最近才出现的主流语言，如果那个设计是后继无人的，那么必定是坏的。

就拿缩进敏感来说吧，算是典型的后继无人，Swift ？ Go ？ Rust ？ Kotlin ？这种糟糕的设计已经被后人全面抛弃。

python 还有哪些糟糕的设计？

以设计的传承性来看，你可能会发现更多败笔，它们已经被历史无情地扔到垃圾堆中了。

毕竟很多东西都有其时代局限性。

[mind3x]

对 Python 不发表意见，不过 Scala 从 2 到 3 是加上了缩进语法块: https://docs.scala-lang.org/scala3/reference/other-new-features/indentation.html 。

[makelove]

其实我以前还在用 python 时觉得缩进也不是那么另人难受，但转了 js 后发现缩进的确不如 {} 实用

至于 lambda 只有表达式就更糟糕了，用 js 的每个人匿名函数用得飞起，估计让他转用 py 发现不能用了要先定义一个有名函数再传名字估计会一脸懵逼

[xupefei]

今天刚碰到一个：isinstance(False, int) = True

我以为我写的是 C😂

[silkriver]

楼上的需求应该用 type(False) == int

[silkriver]

运行任意代码应该用 exec()

[sudoy]

我倒是觉得 python 的缩进语法比 js 的大括号好用，js 写完代码回头去 debug 的时候还得数括号

[15855pm]

@xupefei 这个为啥等于 true ，求解释😅

[pythonee]

GIL ？

[adoal]

矫情

[Kilerd]

你可以吐槽 lambda ，但是锁进这个除了古早时代需要用游标卡尺，但是在现代编辑器下早就没有这个问题了

点进来之前我以为会吐槽 type hints ， 海象操作符之类的，原来是吐槽这些，打扰了

[chengxiao]

这些都不是 python 的槽点，python 已经很好用了，比起这些他最大的错误 就是 慢！

[janxin]

你不可能预见到 20-30 年后会发生什么...

[lizytalk]

GIL

[2i2Re2PLMaDnghL]

Haskell 缩进敏感
（你如此大胆竟然敢喷 Haskell 的语法？（笑

@pythonee 不是 Python 的语言设计，而是 CPython 的实现细节。PyPy 和 IronPython 我记得都是没有这个机制的，也有人提出了一个提案通过介于函数式和 CoW 的形式来移除 GIL 又能适应 C extension 。

@sudoy 这个论点很早在 Lisp 那边被驳斥过了。括号从来不用数，括号不是给人看的而是帮助语法分析器理解的，正确的缩进才是给人看的。
我非常倾向于认为 JS 的自动代码格式化不应该由括号自动产生缩进，而是应该由缩进自动产生正确的括号。

[adoal]

@2i2Re2PLMaDnghL PyPy 也有 GIL……曾经尝试用 STM 来做一个无 GIL 的版本，然后没有下文了

[fgwmlhdkkkw]

确实有一点，其实可以混合支持{}和缩进……

[2i2Re2PLMaDnghL]

@adoal （那大概是 Jython 或者别的什么

[Vegetable]

你的前提可能不太合适，我们不能假设一个语言设计出来就是为了「完美」，少了{}的 python 看起来确实更简洁，有舍有得是常态。不能直接说成重大失误。当然你不喜欢那太正常了，完全合理

[luffy]

缩进做为语法不是问题，
主要是这里是 4 个缩进。而现在流行的是 2 个缩进

[zmxnv123]

本来打了一堆话，后来想想还是全删了，不值得