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

[AndyAO]

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

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

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

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

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

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

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

python 还有哪些糟糕的设计？

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

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

[DOLLOR]

缩进语法不利于在网络上粘贴分享代码。
而且有了缩进语法，行末却还要写冒号，也是匪夷所思的。

[TypeError]

python 最大的问题不是你说的这些，
最大的问题比如：
python2/python3 不兼容，python3 刚出来又没有什么吸引人的特性，导致花费了十来年事件来迁移；
python 设计和 cpython 解释器耦合，导致第三方去掉 gil 、加 jit 等改进必须兼容 cpython ，需要深入 cpython 的实现细节，pypy 到现在兼容性还不太好；
默认参数不能为可变对象，比如 list ，这个问题搞垮了一家创业公司



但编程语言还得看业界需求，设计的好的语言不一定能活得好

[TypeError]

@luffy 我见到的 python go ，Java 代码都是 4 缩进，2 缩进太难看了，只在一些配置文件里看到 2 缩进

[mosom]

2 、3 不兼容真的是大问题（血泪

[robinlovemaggie]

Python 最大的失误就是 Guido 撂挑子，还跑去了某闭源大厂。

[shuimugan]

缩进真的是个问题，我看到好多入门的人在学多线程的时候，在循环里开多线程然后 join 一下等待，还疑惑为什么多线程比单线程还慢。后面一看是抄代码的时候因为缩进问题，join 放错位置了。

[silkriver]

我觉得作为新手程序员和非程序员的首选语言，强制缩进是 Python 胜出的原因……

[whywaoxaks]

最大问题：慢

[arischow]

新手抄代码因为缩进无法运行从而推断语言有问题？

[YvesX]

import this 现在看全都是“想得美”

[arischow]

个人认为 Python 就是没个好爹，少给用户一点自由，再 opinionated 一点可以让不少人消停消停。

[BeautifulSoap]

点进来还以为有高见，结果一半是讲缩进的。

[Huelse]

缩进不算什么问题，就像 rust 的简化语法也不是什么问题，问题是执行效率和可阅读性这两者的统一，我认为 python 在这两点上并没有做的很好，倒是在开发效率和简化问题上无可匹敌

[2i2Re2PLMaDnghL]

@luffy Linux 在用 8 缩进，并且认为其他都是异端，而且认为如果 8 缩进放不进 80 列，那么是你的逻辑堆叠层次太多了

[ytmsdy]

别说什么 Python 慢！绝大部分的程序都没有能够触及到 Python 的设计性能瓶颈，跑得慢绝大部分的问题是没写好！

[Leviathann]

数据是 mutable 的，但是却没有声明关键字

[westoy]

@15855pm

dir(1) == dir(True) == dir(False)有惊喜....

python 的 True 和 False 两个"常量"就是通过两个固定的 longobject 结构体的引用实现的.......

[htaoreg]

@15855pm bool 是 int 的子类吧

[jjx]

eval 有限制不是很正常吗

真要灵活性, 用 exec 完全可以达到 eval 的效果啊

[pmispig]

这些算个鸡儿失误，GIL 都不说