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

[AndyAO]

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

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

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

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

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

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

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

python 还有哪些糟糕的设计？

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

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

[Mark24]

Ruby 没有这些缺点

[krixaar]

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

我也觉得，最近在汉化一个 js 项目（ CyberChef ），结果人家居然配了 ESLint 规则，缩进不对还过不去，明明都用大括号了还缩进，ESLint 设计 indent 这个规则的人那里肯定有什么大病🐶

[woctordho]

其实 Python 也不是不能 lambda 写多行，也不是不能随便缩进（迫真）
```python
def do(*args): return args[-1]

fib = lambda n: do(
fib_tail := lambda n, a, b: do(
a if n == 0 else fib_tail(n - 1, b, a + b)
),
fib_tail(n, 0, 1)
)

print(fib(100))
```

[CosimoZi]

haskell 也缩进敏感, 建议喷 haskell 语法.
无知.

[ruyu]

函数式编程的函数本来就只能有一个表达式

[Donahue]

缩进最大的问题是格式不统一，有时候 ctrl v 需要一个个对着
有些网站复制代码的时候，缩进会乱掉
(doge)

[rahuahua]

@vanton 有了{}也可以有缩进嘛

[oOoOoOoOoOo]

@sudoy 数 {} 比数 Tap 更省事

[ClericPy]

不喜欢和重大失误真的不一回事, 至于楼主的其他论点学习只好 #20 了

最让我头疼的还是协程语法不能像线程一样简洁明了(至少能让我 await 自动识别后面的函数是不是协程也行), 平时用协程要给一大堆不知道应不应该 run_in_executor/to_thread 的玩意套娃快烦死了. 但是再难吃也硬着头皮吃下去了

@sudoy
VSCODE 上个月出了个 editor.guides.bracketPairs, 现在配合彩虹缩进和彩虹括号不那么心智负担了

[XIVN1987]

@xupefei

In [10]: isinstance(True, int)
Out[10]: True

In [11]: type(True)
Out[11]: bool

In [12]: issubclass(bool, int)
Out[12]: True

In [13]: True == 1
Out[13]: True

In [14]: False == 0
Out[14]: True

bool 是 int 的子类，，这可能还真是跟 C 语言学的

[2i2Re2PLMaDnghL]

@woctordho 你不如直接实现一个 Y 组合子，用 lambda 可以编写一切代码。

[void59468]

@15855pm https://docs.python.org/3/library/functions.html#:~:text=The%20bool%20class%20is%20a%20subclass%20of%20int

[abersheeran]

@2i2Re2PLMaDnghL 确实可以实现 Y 组合子

<script src="https://gist.github.com/abersheeran/80709d4ffd7e83c1206dbcc8df11d4d5.js"></script>

[kilasuelika]

@ipwx 我自己用 python 的时候，最烦的就是四个空格和 tab 的区分，还有就是调缩进。
现在慢慢就不用了。我接受 python 应该算早的，高中的时候在智能手机上玩过，但一直不太喜欢。现在主要用 c++，matlab ，mathematica 。

[ipwx]

@kilasuelika 可是，所有编辑器都可以直接用空格替代 tab 啊。。。

包括配置 1 tab = 4 spaces 。。。或者 js 就是等于 2 spaces 。IDE 处理 tab 和缩进是很方便的，回车自动缩进其实也不用按 tab 。

[ipwx]

还有就是选中一块内容 Shift + Tab 是整体取消一格缩进。。。 也都是 IDE 的基本功能

[kilasuelika]

@ipwx 你这个太理想化了，写代码的时候不一定总是用同一个 ide ，大多数时候都不会用 ide 。可能是打开记事本写，可能是打开 notepad++，有时候又是在 jupyter notebook 中写，有时 vs code ，有时就直接在终端里面写。

[ipwx]

@kilasuelika 但是你以己度人了。

事实上我写代码从来都用 IDE ，无论是六万行 C++ （ CLion ）还是 pytorch 模型（ Pycharm ）。Jupyter 我基本上只是在服务器上起 Jupyter Lab 用它的终端，实际写模型还是在 Pycharm 里面，打开它的 ssh 自动同步功能，修改的代码就自动上传到服务器了。

然后我当年实验室里面，二十几台服务器我配的，有共享文件系统。这样的好处是，在自己笔记本上修改了代码，瞬间可以在 20 几台服务器（其中四台 GPU ，共 20 几张显卡）的服务器上同时开多个实例调参数——你只是在各个不同服务器上的 Jupyter lab terminal 里面操作而已。这不比一个 Jupyter notebook 强太多了吗？

此外就是，我当年做研究，代码也是有层次、整理成工程的。甚至我自己都有一套自己的 tensorflow 组件库（后来是 pytorch ），可以 pip install 的。实验室不下十篇论文引用了我的组件库。

而且哪怕不是像我这样工程能力比较强的，遵照我的 workflow ，用起来也很爽。就是参考我上面说的，本地笔记本用 IDE 改好以后，瞬间就同步到二十几台服务器上了。真在截稿前 ddl 疯狂跑参数的时候，这实在太重要了。

啊顺便我自己有一套参数保存、读取和命令行读取的库。这样的话一个 .py 可以瞬间人肉调参十几组同时跑。这也是大前提。

[ipwx]

@kilasuelika 当然后来做公司项目了，那还是必然差不多还是 IDE 优先 hhh 。反正真的上传代码都是 git push ，部署有 CI 。综上，无论是研究性代码，还是工程性代码，其实 IDE 效率都远高于单独用 Jupyter notebook 或者 vscode 。

[ipwx]

@kilasuelika 说起来当年我做一篇论文，曾经有过最多 20 个实验在跑：四个数据集、每组各 12 个参数的组合，一个大表需要跑。那更是不可能复制 50 个 .py 文件或者 50 个 Jupyter Notebook 呗。只能按照我的工作流，实验代码项目化，IDE 里面自动同步到服务器（有共享文件系统，所以同步到任何一台服务器，等于同步到所有服务器）。

然后超参都通过命令行给，每台服务器还当时用了 Dask Scheduler ，一个好了就启动下一个。基本都是第一天挂上，第二天看结果。。。。

我还写了个 Vue.js 的结果收集页面 hhh