Python 之父谈缩进和大括号

不得不承认，他技术比我好，长的比我帅

省流：Van Rossum 没直接回答题述问题，但提到了编程新手在学习和使用 python 时只用缩进能让他们更加快地融入后续语言各要素的学习中，所以他应该还是会选择只用缩进（当然你可以当我这是个人解读）

另外代码缩进真的是个好习惯。
不限于代码，文本缩进也是个好习惯。
所以我现在特别反感 markdown 的一点在于，只有用嵌套列表实现的缩进，没有自然而然的其他语法去实现缩进，比如 4 个空格
&uggggglllyyyyyyy 甭提这种要在文本前插入大串 html 空白字符的丑陋行径了
&uggggglllyyyyyyy 试问谁受得了自己的要输入的话可能还没空白字符占的位多？

我也觉得缩进挺优雅的

就是 if 这种 后面还有代码就很难受，可能是还没习惯吧，之前都是写 shell 脚本，最近刚开始接触 python, 就是没有大括号难受

最好是共存，方便格式化。

当时学 Python 的时候还就是看中了它没有括号的语法。真是萝卜青菜各有所爱。

无论怎么洗，缩进都是个烂设计，代码块的末尾需要一个结束标志，你不喜欢大括号，你可以搞个 end 之类的东西，python 这样搞 auto format 就全失效了，python 的很多设计今天看来不咋滴，比如它把变量的声明和赋值搅到一起也是个不好的设计。

缩进应该是格式化工具帮人做的事，不应该由人来手工缩进。

我觉得缩进应该尽量用于“美化代码”，而尽量不要并且最好干脆不要参与“语法结构定义”的逻辑里。

省流：顾左右而言他，打了十一分钟的太极

缩进是 yaml 一样垃圾的东西

视频中说已经使用括号表示 dict, 没法回头. 那 js 也是大括号表示 object,
在不通的语句下有不同的含义吧.

可行的办法: 新的文件后缀
参考 sass 生态中的 .sass .scss, 本来是基于缩进, 新扩展名支持括号

https://github.com/mathialo/bython
好多年前用过

c++ 出身的， 因为一直习惯不了这个缩进，实在是能不用 py 就不用，如果有一天能共存，我一定高举双手奔走呼告

我觉得差不多，缩进改成大括号并不能让我的代码变得更漂亮。
我 Golang 的大括号，Python 的缩进都用，都察觉不出什么太大的阻碍或难看。
我写 Py 的时间比 Go 长，所以觉得我的 Py 写得比 Go 漂亮一点吧。

复制粘贴一遍回复：

除非你只用一个空格，缩进用空格就是逻辑上扯蛋的，总是无法避免在源文件编码层次上允许光标卡进缩进内部出现“半个缩进”的破坏不变量奇葩状态，跟 malloc 到处乱飞找不到 free 的破烂代码本质上是同种的可恶。顺带还没事 bloat 一下源代码。
虽然（水平）制表符在语义上也不那么适合缩进，但至少没这种低级问题，在许多语言的基本字符集内也没别的得选的。于是高下立判。
注意在根本上，前缀空格干的活是对齐。虽然缩进可以提示对齐，插入缩进跟缩进的理由逻辑上完全是两码事。
至于可读性，py 式缩进直接干掉了 free form 语法允许具有的上下文无关性，分析这坨玩意儿现实就没法只是 parser 的事（想用 parser 做对会极其扭曲），基本只能加语义预处理，又是个不适合机器又不适合熟练的人类阅读者的奇葩设计，纯属没事找事的自以为是了。另一方面，无法局部调整缩进导致传统纸质书那样的分页排版在换页处的可读性极其看脸，一不小心跨页就得数缩进，怎么看都比用括号直接从视觉上显式辅助定位恶心得多。
相对来说，写起来可能还能用 IDE 和结构化编辑器（现在还基本是空气）解决，没读起来那么严重。但是要把这个混淆成可读性，心智多少有些问题。

@youdoit yaml 的垃圾程度比缩进大得多。
@rozbo 共存？试试 Haskell ？
在你显然对被迫记忆上下文相关的缩进的语义（虽然技术上被钦定为语法）没什么经验的时候，姑且还是给你一些反悔的机会吧。

@FrankHB 无所谓，IDE 会帮我。而且我觉得 Python 代码本身写起来很舒服
而就像 js ，就算有大括号写起来还是和吃屎一样难受

@KENNHI 复制的最后一段就是怼借口有 IDE 拉屎恶心读者的。何必凑上来对号入座呢？真要 write-only 舒服怎么不 Perl ？连 IDE 都无关紧要了。
（虽然 py 的 IDE 其实历来不怎么样，不过这里是次要的。）

用缩进表示作用域层次的语言有不少，之所以 Python 会经常因为这事被拿出来说，还不是因为太流行了，阿猫阿狗都觉得自己能指点 Python

既然可读性有没有所谓都会成问题，再提个更一般的现象好了。

其实平心而论，只有 py 式缩进实际并不会浪费我多少阅读源代码的时间，毕竟就算真的要做 semantic transformation 也完全是 one-pass 的，比 Lisp 宏都省事多了（不过 Lisp 宏我真不用傻乎乎去这么理解）。
关键问题是，隐含一个前提：我得假定我看的代码（至少在语法上）是对的。
尽管搞错缩进实在是很低级的问题，以至于这个假设绝大部分时候并不会被违反，存在这个假设本身就令我相当不爽。并且这种罕见性的低效用直接导致了不爽的升级。
——因为为了一个实际罕见的低级错误分支，我不得不在脑子里准备 fallback path ，继续跟 cache locality 过不去。
（ Haskell 也有类似的问题，而且因为对一些上下文混用空白符的检查的缺乏，后果更严重，却反而导致了罕见性的弱化，某种意义上反而没那么恶心了——看，你学了这么多旮旯，也不是用不上嘛。而这类严重后果在 Python ，或者至少是鼓吹了 PEP-8 以后的 Python 中，并不那么显见。）

类似的强迫劣化人脑中语言实现的问题其实很普遍，不是 py 专利。
比如说 C 的声明符语法就被我认为是垃圾设计，除了人和机器的正确实现都麻烦而实际技术好处基本就是省纸这么个可笑的投入产出比（也是低效用的实例）外，它还暗示读者除了理解正确的语法规则，最好需要掌握次等的小聪明——所谓“右左法则”——才能去跟那些学得不到家（不知道正经的声明的形式语法）的 C 用户。这让交流更加困难不说，还嘲讽了正经学习语言规则的用户是傻子。
这里有个类似的罕见性技术细节：所谓右左法则其实绝大多数情况下是形式上正确的，能得到正确的分析结果。但是它依赖读者事先知道什么标识符未被声明，这是一个全局（至少一个翻译单元）的语义性质。于是为了保证正确，我不得不准备两套思路，脑补实现比编译器更复杂的算法——以便回溯出错误时，能和那些不懂形式语法的半吊子用户沟通。而编译器根本不需要鸟这套，照着正式的文法产生式直接实现 parser 就能几乎完全处理所有情况。（几乎是指 C 的文法设计上下文相关的例外，这是另外的糟粕。）
如果抛开罕见性，那么所谓的右左法则和谭浩强之流其实本质没什么区别，都是应当纯粹被鄙视的：鼓励放着正经规则不学，非得去做二道贩子，然后粉饰虚假的“简单”诱骗更多 noob 上当，搞烂整个用户群体。

Py 在这里有点不同就在于形式上由设计者背书，所以不会导致 py 意义上的技术错误。
但是当大量用户依赖 py 入门正经编程甚至理论计算机科学基础的时候，用户会不自觉地试图把 py 的局限性迁移到其它语言上照猫画虎，结果污染的远不只是 py 用户这个群体。
这个客观现象导致我即便无所谓 py 的设计和个别人的口味，也不得不面对这些不论是有意还是无意强迫我把智商下限拉低才配和他们交流的敌人了。
（虽然其实这里有资格到我需要特地婊的大约只有 MIT 的 6.01 。GvR 这种连个 PTC 都要 feel educated 的实在不配。）