Python 为什么如此设计？

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

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

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

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

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

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

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

@junkun #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])。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

我有说过工具不好吗?

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

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

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

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

@mmm159357456

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

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

@hxysnail

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

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