Python 为什么如此设计？

分享一篇文章： zhuanlan.zhihu.com/p/592658877

涉及 Python 语法设计、发展历史、编程思想等话题。

每次看到谈论 Python 的话题我都要去看看人们是怎么强行升华 len(arr)这种写法的。果然没让我失望。

还有就是，现在写文章的人比文章还多了

我认为由个人主导的语言，很多设计都可以归为作者的口味问题
分析它们的优劣是可以的，但是硬找上一堆理由还扯上对世界本质的洞察就实在有点……

我 tm 以为你是在问问题

最后还不是调用__len__魔法方法。

python 既要 function programming 又要 object oriented programming 。但是 FP 中又不支持多行 lambda ，OOP 中 typing hints 又极其弱鸡（最近更新稍微好了点）。我是觉得这几年来进步乏善可陈。

不错，值得参考

它一个外部函数，咋调进去“双下划线”方法的呢？好神奇啊

。。。。python 里又没有 private 的概念，所有方法都是 public ，直接 a.__len__() 就能调用了

其他我都不管，我只知道基于游标卡尺的编程语言不是自我改进就是昙花一现

所谓的 magic 就是语言内部的调用 protocol （规范）。python 魔法方法很多，你甚至可以实现一个__get__的版本。
class Length:
def __get__(self,instance,owner):
return len(instance)

def create(cls)->int:
return cls()

class WithLength:
length = Length.create()
def __len__(self):
return 10
with_length = WithLength()
print(with_length.length)

非常喜欢游标卡尺这个表达。

锁进语法就是垃圾。

Python 语言的定位挺适合缩进语法的

哦。我应该是搞混了
前后双下划线是可以被外部调用的
仅前双下划线是 private

写的很好，对我很有启发

＃13

草，你这么一说，的确是哈：

__str__()是可以被外部调用的。
__foo()是 private 的，不用奇技淫巧的话外部是调用不到的。

但是我没有印象在哪看到说前后双下划线是 public 的。
我一直只记住了前双下划线是 private 的。
突然有点蒙了。

所以，从外部调用“仅前双下划线”的奇技淫巧到底是什么呢？

name mangling

哦，需要先 dir 一下

＃16
类似这样的对应关系，你自己加上前缀就可以访问到了：

＃16
_A__b_的箭头指错了，应该指到__b_。

不少都是强行找理由
某些问题就是设计的菜或者个人口味问题

已经开了几十年了, 怎么还没消失?

我对 python 的语法没有意见,有意见的是性能低和部署麻烦,其它方面很喜欢

提出不同意见容易，再补充论据支撑观点困难。建议你补充，否则可以认为你的留言毫无意义

文章提到 4 个原因，前三个关于优劣，“世界本质的洞察”是我个人的发挥，不代表设计者的观点。但是，我还是愿意强行拔高，因为我需要找到一些文字来表达自己对这种设计拍案叫绝的情绪。就像足球迷愿意说梅西“封神”了，啥，没感觉的人可能质疑，取得再好成绩也不至于扯上“封神”吧……

谢谢～

不管认不认同，能把自己的观点整理成本章写出来就很棒。表达观点很简单，但是论证观点却很难

口味问题严重到一定地步，还真可以说明对世界的本质缺乏洞察力。比如看看这里 GvR 是怎么认怂的：
neopythonic.blogspot.com/2009/04/final-words-on-tail-calls.html
作为对比，这方面什么叫有洞察力的：
www.researchgate.net/profile/William_Clinger/publication/2728133_Proper_Tail_Recursion_and_Space_Efficiency/links/02e7e53624927461c8000000/Proper-Tail-Recursion-and-Space-Efficiency.pdf
注意考察这里的分析对具体（任何允许递归函数调用的）高级语言的具体设计基本中立。
设计通用语言的有义务理解计算模型和理论 CS 教育的影响。MIT 的某课程改用 Py 在这方面就是一种消极的影响，尽管这锅不是 GvR 背的，但没有 GvR 瞎搞，这个世界恐怕会好很多。
倒不是说 GvR 多大奸大恶，但是一个平庸的选手占据了过于显著的地位浪费资源引领菜鸡互啄，这是业界的不幸。

当然这文章里提到的东西普遍比较水（作者的洞察力相当可疑）。
比如什么 i++，根本就是 artifact ，该问的是本应当是为什么 C 之流使用这种设计，而不是 Python 不使用这种设计。Ken Thompson 搞出这货的时候还有节约代码长度的技术作用（类似的一个更著名的语法是 C 的声明符），现在剩啥？ Python 没有稀里糊涂照抄这种设计，反而是正常人的思路。
这里唯一跟“本质”洞察力能扯上关系的是 lambda 的设计（其它大都是比较菜的历史和工程 tradeoff 问题）。这个例子中，社区里脑子正常的更多点，比 GvR 更加分得清限制的工程复杂度后果；不过半吊子妥协搞得不伦不类也许是更差的结局。当然，这点也说明“由个人主导的语言”早就寄了。不过如果让这 BDFL 一路作死，说不定现在就没那么多不求甚解的口味奇怪的用户了。

＃25 我认为能够让人拍案叫绝的，应该是足够巧妙的设计。len 这种东西我认为完全是受过程式思维的影响（当然并不是说过程式就是落后的），一堆脚本语言都是这么干的，不足以称之为巧妙。

＃28 嘛，对于早期的语言设计者应该要宽容一点，毕竟他们是趟坑的人，而我们是站在巨人肩膀上的人（除非是在 21 世纪还在以 70 年代的思维设计语言

len 这种东西说不上多巧妙，但是现实中几个值得一提展开的点（还是普遍到跟 Python 不需要直接关系）。
我确信 GvR 始终没摸到这方面的坑的主要边界，以至于解释中很大程度都是 ABC 的历史包袱。

1.关于混合所谓自由函数和方法的问题。
其实大多数语言都还没有复杂到要你纠结坑的地步，但也存在进退失据的例子。搜索 C++ UFCS 有真相。
因为，认为 len(x)和 x.len()不是一种含义会造成明显的不一致，以至于有不少人认为这两种语法的含义干脆合并得了，定义一个就能两用。但这样就有个灵魂拷问：既然允许 len(x)，为啥还要发明 x.len()，浪费一个不同的语法？然后什么 customization point 之类的妖魔鬼怪上来凑一脚，不忍直视……
所谓“前缀符号更可读，简单胜过复杂”其实倒并非没有道理。
仔细还原这类语言的语义规则，*this 被作为隐藏的参数，但这其实还有个更一般的形式——静态环境（在静态语言中通常被处理成不可见的符号表）。
隐藏显式名称查找的语法，都写成前缀，比如 Lisp 语法：(len x)——就能发现完全是一回事。是不是要依赖 this/self ，只不过 len 到底是从哪里来的罢了，这完全可以作为实现细节，而实现这里的简单。

2.这玩意儿是个普遍的问题，和 OOP 本没多大关系。
扯上 OOP 的关系，大约是某 PL 大手子的功劳。
这样的理解原则上就是歪的，应当予以纠正： stackoverflow.com/a/74375048 。

无论是误会的形成还是传播，去除脏话以后，拍案叫绝的成分都是够多的。

顺便，至于 0 索引，那倒是有点洞察世界的味道，但是只字不提 EWD831 （ www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831.html ）这种常识性文献，多少有点过分。
原文评论区有人指出了这点。GvR 只是提供了关于 slice 的新发明，然而除了提了一点避免 off-by-one 错误问题外并没有涵盖 EWD831 的内容。
EWD831 距离所谓的世界的洞察也是有一段距离的，因为它只是很隐晦地顺带提到了根本原因：基数(cardinals)和序数(ordinals)的区别。
这种洞察，对有点数学（哲学）系统训练的用户来说，实在过于基础了，也许不值一提。不过放在这种文献中解释，从一般情形（而非举例）证明为什么索引应该从 0 开始，本应当是有必要的。不过作者并没那么做。

＃24 只因提出了意见而没有补充论据就说留言毫无意义的话，建议阁下只发表在国际期刊上，而不是普通人都可以发言的论坛上。我认为本论坛并没有要求回帖者进行大段论述的要求。

其次，我的个人观点就是阁下在强行升华，或者我换种说法，是把一个没有什么意义的东西强行赋予了意义，或者我换种阁下用的说法，「你的强行升华毫无意义」。

我也可以像阁下一样，去把其他语言吹嘘一番。比如我日常使用的 Ruby ，吸取了 lisp perl smalltalk 的精华设计，用对象+消息的方式来调用功能，还融入了方便好用的正则处理和函数式表达，你 Python 杂乱无章的设计，只能单行的 lambda ，满地的 self ，也好意思拉出来秀设计？

我这么说完下面肯定一堆喷我是傻逼的，对不对。

论坛混了那么多年了，我年纪也大了，放到十年前我肯定来和你大战几十回合，不到天亮不罢休。现在我也就吐个槽，看过的就让他去了。你把 Python 吹得再好或者再差，人们心中自有评判，觉得他设计成神的人也不会改变，觉得他设计成一坨的人也不会改变。反正到最后，工资给得高的公司和职位，不都是写 Java 的么 ┓( ´∀` )┏

如果是设计 ABC 那时候的 GvR ，那么是可以宽容一点。但设计 Python 的 lambda 的 GvR ，已经不太能那么让人宽容得起来了。说得严厉一点，就是德不配位。
我举的有洞察的对照例子，也都是年代明显更早的论述。
真心要称赞的话，大概 GvR 就一点做得比较突出：没有直接乱缝合别家设计。虽然很多设计拉胯，来源基本上是他自己（比如大多数 PEP 的质量相对无理的原始设计，质量看上去都算好的），那么就不至于稀里糊涂搞得大多数人最终都不清楚为什么要有 i++之类的情况，纠正起来也容易得多。

python 最大的问题,还是一开始是单人项目,没有 jit,现在 c 库多了,jit 不好搞了

看完这段话

回到前面的问题：为什么是 len(x) ，而不是 x.len(x)，这根源于 Python 的什么设计思想呢？
Python 之父 Guido van Rossum 曾经解释过这个问题（＃TODO: add link ），有两个原因：
对于某些操作，前缀符比后缀更好读——前缀（和中缀）表示法在数学中有着悠久的历史，其视觉效果有助于数学家思考问题。我们可以简单地把公式 x(a + b) 重写成 xa + x*b ，但同样的事，以原生的面向对象的方式实现，就比较笨拙。
当读到 len(x) 时，我就知道这是在求某对象的长度。它告诉我了两点：返回值是一个整数，参数是某种容器。但当读到 x.len() 时，我必须事先知道某种容器 x ，它实现了一个接口，或者继承了一个拥有标准 len() 方法的类。我们经常会目睹到这种混乱：一个类并没有实现映射（ mapping ）接口，却拥有 get() 或 keys() 方法，或者某些非文件对象，却拥有一个 write() 方法。
解释完这两个原因之后，Guido 还总结成一句话说：“I see 'len' as a built-in operation ”。这已经不仅是在说 len() 更可读易懂了，而完全是在拔高 len() 的地位。
这就好比说，分数 ½ 中的横线是数学中的一个“内置”表达式，并不需要再实现什么接口之类的，它自身已经表明了“某数除以某数 ”的意思。不同类型的数（整数、浮点数、有理数、无理数...）共用同一个操作符，不必为每类数据实现一种求分数的操作。
优雅易懂是 Python 奉行的设计哲学，len() 函数的前缀表达方式是最好的体现。

我概括为：为什么前缀 python 的前缀 len()比后缀 len()更好呢，因为 python 的创始人认为前缀更好（原因有二），所以“I see 'len' as a built-in operation ”，所以 python 中的 len() 函数的前缀表达方式是最好的体现。

这就像：为什么我的回复是最好的回复呢，因为我这个回复的作者觉得自己的回答字数多，因为我舍得多花几个铜币，所以我就是最好的回复这种荒谬的自证一样，牛头不对马嘴。这可能不是完全的自证，但颇有自证的味道。这种文笔。甚至我一度怀疑我阅读理解能力出现了下降。

然后还“I see 'len' as a built-in operation ”，自证的同时，还强行升华了下 len()为哲学，拔高 len() 的地位。其实我对 python 是不反感的，每门语言都有自己的独到之处，但是这种自证和强行升华。

我要是自定义 class ，我绝对还会再选择实现.len()函数

并非想引战。我可能有盲区导致眼界不广，只看到一个设计觉得很赞就说出升华的话。所以才想请教为什么你会觉得它很一般。你最初的语气让人不爽。但我还是想看到一个对于 len () 的友善的有理据的补充

“巧妙”有抖机灵炫聪明的危险倾向。我不会认为 len 是巧妙的。它就简单直观，就是呈现本来事物的本来面目的那种简单，而不是引入模式化、附加非常多基础概念的设计

还是发到推广节点吧……

关于 len(arr) vs arr.len()这个，如果只是单独一句表达式的话，它俩就没啥区别。
但如果是一长串的话，比如 a(b(c(d(e(f(g))))))与 a.b().c().d().e().f().g()，后者肯定比前者更清晰。
所以我比较期待能有类似管道符一样的方式，把函数名称后置，比如 arr |> len

谢谢建议，但 Python 就是最合适的节点

很奇怪你竟会阅读理解出那样的结论。原文的逻辑：提出为什么，给出原因，我认可原因并补充更多的解读。

很多 modern 编程语言都支持 UFCS, 比如 Rust, D, Nim ，a.len() 和 len(a) 语义上相同。

pass 是 Python 独有的一种空操作，其它语言并没有这样的设计

Nim 语言也有类似的 discard 空操作；支持 discard 字符串用作注释

用 .len() 的话，问题是没有办法引用一个通用的函数，在一些场景不那么简洁了。
比如 map(X, list) ，对于 list 内的元素是任意类型的情况，这个里面 X 填什么？如果设计的是 .len() 的话，用类方法 str.len, list.len, dict.len 都不符合，要么就要写 lambda 了，而 GvR 本身也不是很喜欢 lambda. 而用函数的话，X 就可以直接写 len ，从这点上 len() 比 .len() 好一点。

而且缩进这个，我一直都不理解为什么网上有这么大的反感，至少我个人从来没被困扰过。无非就是复制代码的时候不能无脑粘贴？

因为你用 Python 之父的话回答了为什么 Python 的前缀更好，有种自卖自夸的意思，你所谓的自己的解读也不过是把他的话用另一个方式说一遍。换言之，我若是另一种范式的追随者，我完全可以用一样的逻辑说另一种范式更好。更别说上升到哲学的高度了。你文章里这一串解读，还不如 43 楼这样的实际理由给的直接

缩进确实是个不好的设计,浪费了人的精神花在这方面,甚至引发了空格和 TAB 的战争!

别的语言就没有空格和 TAB 战争吗？而 python ，至少我用过的所有库都是用 4 个空格的，说战争也轮不到 python 。2. 我个人认为正常写代码就是应该自觉做好缩进的，无论什么语言。自动格式永远只是辅助手段。其次，我实在是不觉得代码编辑器输入缩进能费多少精神，输入完冒号回车就自动加缩进了，不需要就按一下 backspace 。

其实编程语言就是个工具，看应用场景，趁手就用，不顺手就换，哪来那么多教义，搞得跟宗教一样

所以是
哪年的哪个国际期刊或
哪年的谁的的哪个论文
提及了 python 语法设计的问题
？

我觉得人是最不可控的因素，如果是一个人的项目那还好说。反正我带的 Go 项目，本身自带自动格式化，但总是有人懒得配……除非大团队有精力做 code review ，否则最后肯定是一团乱糟糟的炒面

别的语言真没有 PYTHON 这么严重,TAB 和空格混用就报错.这多多少少是个问题,我不相信你没碰到过因为缩进导致运行出错,从而要调整的问题.你也不用嘴硬,自己统计下有几门语言采用强制缩进这种特性.

这倒是习惯就好，我一开始也感觉很烦，但写多了就觉得还好

要搞前缀那最好就搞成 julia 那样，现在这样真的有点不伦不类。（而且几乎所有函数都是 data-driven 的 julia 还能比 python 快个几十倍）

Python 用的不多，但我用 GDScript 的时候真的被缩进语法烦死了。现在我都尽可能避免用缩进语法的语言写比较大的项目。

一，TAB 和空格混用报错这个，我编辑器开了 softtab ，所以不会遇到这个问题。另外，难道 TAB 和空格混用是你的 code style ？其二，是缩进导致代码出错，还是代码逻辑就写错了？还是不看代码逻辑就直接复制导致出错。最后，“真理掌握在少数人手上”这个命题，赞同的人占多数。
这不是正说明了强制缩进的好处吗？不好好缩进就报错了。

现在已经在大力推空格缩进了。pep8 就规范了尽量优先用空格。
如果用 pycodestyle 或者 flake8 之类的东西做格式检查，用 tab 默认都会有 warning ，W191 。
我用 emacs 本来准备改 tab ，除了编辑器本身的设定，还有各种乱七八糟的东西全部都要改，被劝回空格了。
其他 IDE 有没有关掉这个默认配置我就不知道了。

我说的也是仅限于 Python ，Python 的语法设计是在强制缩进的平衡点上的。别的语言不一定也是这样，比如我就觉得 yaml 的缩进语法就很难堪。

不是,你们为什么为明显会消耗程序员精力的特性说好话,PYTHON 本身就是作者很早以前创建的脚本语言,它有自己的优点,也存在各种问题.

比如以前没有显式的类型标注,后来不也加上了嘛,这就是在弥补不足.是不是没出这个类型标注之前,你们这些爱好者也要说:PYTHON 不需要类型标注

至于强制缩进,有点好处,会让编写者注意代码格式和段落,但我在使用过程中感觉不爽的是出错了检查费时间,特别是代码一长,真的要带个游标卡尺.经常要在服务器上 VIM 改个脚本,感觉缩进给我带来了麻烦.

哈哈,还是你好笑哦

你看看你自己写的这句话,是不是逻辑矛盾了

[最后，“真理掌握在少数人手上”这个命题，赞同的人占多数。]

“真理掌握在少数人手上” 这句是真理吗?如果是,那"赞同的人是多数"?
如果我不赞同"“真理掌握在少数人手上”",那我是掌握了真理了,还是多数人掌握了真理?

你这不是和"上帝是万能的",但"上帝能创造出一块他搬不动的石头吗？"一样的经典

[TAB 和空格混用是你的 code style ？]

说实话,我写 C＃,JAVA,JAVASCRIPT,GO,VB,SQL,OC,SWIFT,RUST 甚至 HTML,CSS 的时候,根本不关心是 TAB 还是空格,一般情况下 IDE 格式化一下就行了,写的时候多一空格少一 TAB 根本无所谓,不有付出精神在这方面,除了 PYTHON 和 YAML 这两货要注意...

以前就没有显式的类型标注了吗，并不是。以前的代码，类型标注会写在函数注释里。现在的这个类型标注实际上也就是一种注释。
其次，我觉得你是不是应该考虑一下是（可能未配置好的） VIM 带给你困扰，还是 python 带给你困扰。

你看不出来这是个反讽句，其表达的意思是，正确与否不在于支持的人有多少吗？

什么时候写在"注释"里也算"语言特性"了?

如果一种语言特性带来烦恼,就得怪 IDE,EDITOR 不好?

算了,不扯了,估计永远扯不清.缩进,估计喜欢的人很喜欢吧.存同求异了.

我认同 [正确与否不在于支持的人有多少]

不过大部分情况下,主流的选择是更好的选择.类似适者生存.大多数人的选择,适合大多数人.

同理，主流不代表更好。适者生存，细菌才是数量最多的生物。

你也说了写别的语言要用 IDE 格式化一下。配置好的 VIM ，也不会出现 TAB 和空格混用这个问题不是？也会直接警告空格数量问题。再者，没有 IDE ，你是不是就不管 code style 了。从这个角度上来说，python 这样强制缩进的，是更有利于写好的代码的。

＃43 所以很多 OOP 语言的函数式简写都是指对象方法调用。（例如 Ruby 中 X.map(&:size)指对每个 entry 调用.size()方法。Java 中的 Class::method 也是指对 Class 类型的 entry 调用.method()。）
真要说的话是 Python 这样对象风格和过程风格混用非常严重的语言才会有的问题。

比如我随便找了个解释 Python map 的例子，是这么写的。
def square(x) : return x ** 2
map(square, [1,2,3,4,5])
＃=> [1, 4, 9, 16, 25]

但 OOP 正常的设计是给 Number 加一个 square 方法，然后去调用 map(lambda x : x.square(), [1,2,3,4,5])。

＃56
“但我在使用过程中感觉不爽的是出错了检查费时间”
保持良好习惯，使用现代化的工具，缩进压根就不会是负担...

“特别是代码一长,真的要带个游标卡尺”
代码嵌套层级过多本身就是不利于阅读的，无论是 Python 社区一直以来的推荐做法还是各语言的实际情况都是如此。
而单纯代码长、层级不多的情况，本身也不需要在意缩进问题，只要根据上下文确定缩进程度就行了。

“经常要在服务器上 VIM 改个脚本,感觉缩进给我带来了麻烦”
VIM 一样可以做到缩进检测、标注的，并且也一样可以做到比如按 Tab 键输入四个空格之类的效果。

你所有的描述都是带来的负担:
良好的习惯,现代化的工具,限制代码长度,配置好的 VIM
语言强制要求我这样在的习惯那样的习惯,不好

用别的语言不考虑缩进吗？全部都在一个缩进等级上写代码，真的有可读性？

不是，觉得 python 反人性的为啥要点进来留言呢？右上角的×消失了吗

＃53 我没说过这样不好，习惯了就还好，有好有坏吧。我想表达的意思是，强制容易劝退初学者而已。另外你提到真理掌握在少数人手上，这没毛病，我也认同。可我项目做大，得跟大多数人合作……Go 项目有自动格式化都一堆人不会主动配置，Python 项目想统一 style 应该会更累。

看到满天飞的 python 语言培训班，各种广告《财务 /HR/项目搞了一晚上才搞定的事情，同事一小时就弄好了，原来 ta 学了 python 》就知道这门语言的下沉肯定很低。

下沉的语言要迎合群众，语法没必要那么讲究，松松垮垮的。虽然哲学是只有一种写法，但是在群众的努力下，其实已经写法五花八门了。有各种各样能解决奇怪问题的模块，这样的语言有生态就不错了

至于上限有多高，这就懒得讨论了，因为到最后必然是口水仗。

个人的话，我倾向于研究一些其他语言，免得到时候要教朋友 4 年级的小孩，和他们讨论 python 。不懂 python ，就没这个烦恼了。

＃67
1 、如果你认为良好的习惯是一种负担，那为什么不退回到原始社会的状态生活呢？现实生活中有无数习惯问题，你无意识中养成了的、让你感觉舒适、给你带来好吃的习惯也有很多，为什么现在反而觉得“写一段看着舒服、整齐的代码”这个习惯是一种负担？你不觉得很奇怪吗？

2 、人类之所以发展到今天的地步，就是因为会用工具、会用好的工具来提高效率，并且很多你已经习以为常的事物都是基于现代化的工具来高效地实现的，为什么你没觉得那些是负担？有没有想过这个问题？

3 、并没有人限制你的代码长度，你想写多长都没有问题。问题根源前面已经说过了，所谓“要用游标卡尺”的主要原因在于代码嵌套层级过多，而这种状态的代码本身就是不利于阅读的，无论是用啥语言都一样。说白了，这是你自己的做法产生的问题，是你自己让自己难受，Python 的缩进机制只是让这个问题更加明显了而已，问题本身并不在缩进上。

4 、配置好的 VIM 本质上就是一种现代化的工具，对于一个长时间经常使用的工具而言，稍微花点时间配置好甚至做得可复用，不难吧？你买东西都可能会稍微挑一下才买，为什么一个长时间经常使用的工具反而不愿意花点时间了？和第二条同理，你有想过这个问题吗？

缩进的最大问题是你永远不知道你从网上或者其他地方粘贴的代码缩进是否正确，而且一旦不正确还会非常麻烦。
python 的最大优点是库多，缺点大概是几乎所有其他方面。

我对 Python 最大的意见就是性能很差，并发不行

但是，重点是 python 是动态类型的，所以一个列表里面不一定是同一种 class 。如果是同一种 class ，那直接用 Class.method 也可以实现 Java 的效果。但是如果 list 里面是不同 class 怎么办，再用 method 不就只能用 lambda 了。

存在即合理。这个区骂的人再多，也改变不了 Python 流行度在前列啊。性能问题又不是一天两天了。

动态类型可以 duck typing 。这事在 Ruby 里都不是事，因为 Ruby 里方法调用是向对象发送消息（可以理解成 obj.method(arg)就是 obj.send-message('method', arg)）。只要对象愿意接受消息，程序就可以正常跑，无关类型。这就是为什么 Ruby 里的函数式只需要发送 method 而非 Class.method ，因为其实和 Class 没什么大关系。

1 、如果你认为良好的习惯是一种负担，那为什么不退回到原始社会的状态生活呢？现实生活中有无数习惯问题，你无意识中养成了的、让你感觉舒适、给你带来好吃的习惯也有很多，为什么现在反而觉得“写一段看着舒服、整齐的代码”这个习惯是一种负担？你不觉得很奇怪吗？

勤洗手是好习惯,但是在荒漠里,沙漠里缺少水的地方,还要勤洗手就是变态.

我有说过工具不好吗?

缩进过多,不是我的问题,所有人都会引缩进过多的代码.比如你崇拜的 PYTHON 里的官方库.

经常临时管理 LINUX 机器,还有可能是临时开的,有时还有修改下 DOCKER 里的,你是说花费时间执行处理一遍这些机器里的 VIM 配置修改是合适的?你有想过这个问题吗?自己平时只用一两台机器的场景,不一定是别人的场景,别太自我了.

不是，觉得 python 反人性的为啥要点进来留言呢？右上角的×消失了吗

不是,你觉得别人的回复不爽的为啥要回复呢?直接电脑关机吧,眼不见为净.
一个论坛,只要不违反社区规定,为什么就不能进来留言呢?

这倒是习惯就好，我一开始也感觉很烦，但写多了就觉得还好

写习惯了是没关系了.
我看过一个人的留言,说写 PYTHON 缩进对齐很习惯,然后去写了 JAVASCRIPT 一段时间,后来回来对 PYTHON 又不习惯了...
我认为强制缩进其实不是大问题,忍忍就过去了,但我不认同强制缩进是一个绝对无瑕疵的特性,甚至无瑕疵到批评它都会被人攻诘的地步...
像 GO 的 Error,以及泛型,也被人质疑,但真没看到拥护者这么激烈的反应.

合速度

Python 为什么如此设计？

近期文章

热门推荐