python 系统性的限制了代码的灵活执行,不管是 lambda 还是 eval 都只能运行表达式,应用场景十分有限,极大的限制了 python 语言的表现力。
本来能够很容易就写出来的代码,需要绕弯子。
这种限制在当前没有任何站得住脚的合理解释,非要说就只能扯 pythnoic 意识形态大旗。
python 还有个更糟糕的设计是用缩进当做语法,也许在 30 年前能少敲几下键盘,或者让缩进看起来更一致和美观,但是现在的各种 IDE 全都能自动解决这些问题,根本就不需要人操心。
不过这些设计上的问题总会有些争论的,毕竟大家对自己常用的工具都挺有感情的。
设计是好的还是坏的,到现在是否还合时宜,有个更客观的评价标准,就是那个设计是否影响到了最近才出现的主流语言,如果那个设计是后继无人的,那么必定是坏的。
就拿缩进敏感来说吧,算是典型的后继无人,Swift ? Go ? Rust ? Kotlin ?这种糟糕的设计已经被后人全面抛弃。
python 还有哪些糟糕的设计?
以设计的传承性来看,你可能会发现更多败笔,它们已经被历史无情地扔到垃圾堆中了。
毕竟很多东西都有其时代局限性。

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

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

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

今天刚碰到一个:isinstance(False, int) = True
我以为我写的是 C😂

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

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

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

这个为啥等于 true ,求解释😅

GIL ?

矫情

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

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

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

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

GIL

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

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

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

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

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

(那大概是 Jython 或者别的什么

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

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

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

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

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

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

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

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

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

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

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

最大问题:慢

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

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

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

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

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

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

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

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

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

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

bool 是 int 的子类吧

eval 有限制不是很正常吗

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

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

“默认参数不能为可变对象,比如 list ,这个问题搞垮了一家创业公司”
这个真的是大坑。

用缩进表示结构的另一个主流语言是 Yaml (虽然只是标记语言,不是编程语言)。

彼之砒霜,吾之蜜糖。

要不是我写了三年 python 你说的我就信了
闭包那帖子也是你发的吧,看了那帖子后,看到这个吐槽 python 的我就觉得。不好意思打扰了。

Native Extension 需要和解释器内部实现耦合这个问题 Ruby 也有,其他解释型语言应该也有。解决办法之一就是像 C++或者 JavaScript 这样定个标准,不同实现都按照标准的来,这样 Native 扩展也能有一套统一接口。不过这些脚本语言都是靠一个实现发家的,自己给自己做个 Spec 没啥动力,也不够灵活,所以都拒绝搞标准,实现即标准。

cpython 慢没办法回避的. 看隔壁 ruby 的 mri 从 2.0 开始到 3.0 一直在优化性能, JIT 已经是成了解释器标配.
而 cpython 从 2 升级到 3 解释器性能还是大幅倒退的... 最近 3.10 才总算是比 3.8 快了那么点

GIL !

都来说说林志玲的脸到底哪里最难看

Python 基本上是成也 CPython ,败也 CPython 。

基本上很多核心设计都是为了 glue c extension 而存在的。。。这个嘛,对于 web developer 就是傻逼,对于 data scientist 就是圣经。其他任何语言,包括 ruby, java, c#,哪个比 python 更容易黏合 c/c++ 扩展上机器学习、神经网络的?顶多还有个娘胎中的 julia 。

因为有了 GIL 和引用计数,不需要考虑多线程,是个会写代码的基本都能包装一个 C++ 的算法给 Python 。。。

搞(数学)算法的,大部分人都没有多少编程功底。但是他们能贡献大量算法,才有了今天的数据科学的繁荣。

如果加上 JIT 。。。

看看 pybind11 和 V8 bind 在 C++ 里面的巨大编程难度差别就懂了。。。

燕雀安知鸿鹄之志

你这是本末倒置,缩进是给人看的,括号才是给机器看的。

没有缩进的任何代码,人来看都很费力。

很有道理,所以 Python 除了数据分析和 AI ,搞其他的都是天然劣势。

好家伙,数括号才是最蛋疼的吧

就算用括号,也有自动格式化啊,为什么要数括号?

意思是,既然只有正确缩进了,大家才能看得清,那“缩进”本身就不再是“自由”,本来就是 must 。

而且既然每个语言都有自己的“缩进个数规范”,那本来这也不是“自由”,本来也是 must 。

只不过 python 把这件事放到语言层面规定了下来而已。

所以只是大家不爽它不自由,而不是缩进本来有错。

按你的逻辑,IDE 也有自动缩进辅助啊,也不难写 hhh

那这不是既要又要了嘛,没有银弹的

Ruby 没有这些缺点

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

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

其实 Python 也不是不能 lambda 写多行,也不是不能随便缩进(迫真)

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))

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

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

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

有了{}也可以有缩进嘛

数 {} 比数 Tap 更省事

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

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

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

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 语言学的

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

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

确实可以实现 Y 组合子

.wwads-cn { border-radius: 3px !important; } .wwads-text { color: var(--link-color) !important; }