为什么 Python 不需要每个缩进级别恰好有四个空格？
空格在 Python 中具有重要意义，因为代码块是通过缩进定义的。
此外，Guido van Rossum 建议每个缩进级别使用四个空格（请参阅 PEP 8：样式指南Python 代码）。
每个缩进级别不需要正好四个空格的原因是什么？有什么技术原因吗？
似乎所有可以用于使空白定义代码块的参数也可以用于为一个缩进级别（例如四个空格）设置精确空白长度的参数。
Whitespace is signification in Python in that code blocks are defined by their indentation.
Furthermore, Guido van Rossum recommends using four spaces per indentation level (see PEP 8: Style Guide for Python Code).
What was the reasoning behind not requiring exactly four spaces per indentation level as well? Are there any technical reasons?
It seems like all the arguments that can be made for making whitespace define code blocks can also be used to argument for setting an exact whitespace length for one indentation level (say four spaces).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
没有技术原因。将 Python 解释器修改为每个缩进级别恰好需要四个空格并不会太难。
以下是其他缩进级别的一个用例：在交互式解释器中输入内容时，使用一空格缩进非常方便。它节省了打字时间，更容易正确计算空格数，并且可读性不是主要问题（因为代码甚至没有保存在文件中）。
There are no technical reasons. It would not be too hard to modify the Python interpreter to require exactly four spaces per indentation level.
Here is one use case for other indentation levels: when typing into the interactive interpreter, it's very handy to use one-space indentations. It saves on typing, it's easier to count the number of spaces correctly, and readability is not a major concern (since the code isn't even saved in a file).
我刚刚在 [email protected] 邮件列表中遇到的另一个案例 - A使用 Python 工作的盲人程序员使用阅读器程序 - 显然阅读器程序不太喜欢多个空格，因此对他来说使用单个空格更容易。
确实没有什么好的或技术上的理由要求正好 4 个空格，而且我认为反对这一要求的最佳论点是程序员讨厌受到限制，尤其是愚蠢且有些武断的规则。当然，我们都同意 4 个空格是最好的，而且我们大多数人都让编辑器自动设置缩进，但有时您不想使用 4 个空格 - 一次性脚本代码等 - 您现在已经疏远了一位程序员，他觉得任意（风格）要求的粉碎手。
由于某些原因，空白的重要性对于大多数人来说并不是问题。首先，我想不出有哪个（好的）程序员会认为正确的代码格式是一件坏事。其次，逻辑要求我们将代码分成块。许多语言使用 {} 分隔符。在装配中通常是标签。 Python 对空格的选择实际上是相当自然的，至少对于英语来说是这样。当您阅读一本书、一份报纸或一篇博客文章时，当有人引用时，通常会缩进。段落之间由一两行空行分隔。章节通常由一页末尾的空格和下一页开头的空格分隔。因此，空格是一件好事，但强迫程序员遵守你的特定标准会让程序员用他们的时间去做其他事情。
Another case that I just encountered on the [email protected] mailing list - A blind programmer who is working in Python uses a reader program - apparently the reader program isn't terribly fond of multiple spaces, so it's easier on him to use a single space.
There's really no good or technical reason to require exactly 4 spaces, and I think the best argument against requirement is that programmers hate to be restricted, especially by stupid and somewhat arbitrary rules. Sure we all agree that 4 spaces is best and most of us have editors automagically set our indentation, but on the occasions you don't want to use 4 spaces - one off script code, etc. - you have now alienated a programmer who feels the crushing hand of an arbitrary (style) requirement.
The importance of whitespace isn't a problem for most people for a few reasons. First, I can't think of a single (good) programmer who would argue that proper code formatting is a bad thing. Second, logic requires us to separate our code into blocks. Many languages use {} delimiters. In assembly it's usually labels. Python's choice of whitespace is actually fairly natural, at least for the English language. When you read a book, or a newspaper, or a blog post, when someone makes a quote it's usually indented. Paragraphs are separated by a blank line or two. Chapters are usually separated by blank space at the end of a page and blank space at the beginning of the next. So whitespace is a good thing, but forcing programmers to adhere to your particular standard will get programmers to go do something else with their time.
请参阅 PEP 666 - 拒绝愚蠢的缩进
See PEP 666 - Reject Foolish Indentation
使用 1 个空格（或制表符）可以在进行代码高尔夫时节省空间 :-p
Using 1 space (or tab) saves space while code-golfing :-p
Joel 的最佳软件写作选集始于 Ken Arnold 有趣且具有挑衅性的文章“风格就是实质” ”，您还可以在此处阅读 Ken 的帖子。这是一篇经过充分论证的文章，其论点是“从我们现在所处的位置到不再担心风格的唯一方法就是将其作为语言的一部分强制执行”。
这是我读过的唯一一篇建议语言编译器应该锁定样式的每个方面的文章（例如，您关于锁定缩进量的想法将是其中的一部分 - 而不是Ken 过去的主要贡献是 Jini、curses、javaspaces、rogue 和 Corba 的一部分，与 Python 无关）。它提出了非常好的观点，并且在在线版本的评论中您可以看到一些对立的观点（唉，不一定同样得到很好的争论）。
我确实觉得讽刺的是，一位回复者谈论“Fortran 及其强大的格式规则”；这听起来像是一个从未使用过 Fortran 的人，或者对它的了解非常肤浅和边缘化的人。您知道多少种语言可以在哪里书写，例如
……？在 Fortran 语言中，你可以！在标识符和数字文字中，空格是不相关的，并且被编译器忽略，因此您不必使用下划线或驼峰式大小写来使多字标识符可用（只需在单词之间使用空格！）并且很容易使大数字可读也。有些语言确实采用了这种规则，但大多数语言都禁止标识符和数字中存在空格。
当然，风格灵活性总是伴随着错误的风险，例如，在 Fortran 的情况下，
将数字 1.5 分配给变量 DO10I，而
从这里到第 10 行的块上几乎无法区分的循环五次（I相信现实世界中存在这样的错误——点而不是逗号极大地改变了代码的含义——曾经损坏了太空任务，但不记得确切的细节）。
所以，请不要以 Fortran 作为支持或反对“锁定”的例子，因为在许多风格方面它是如此令人难以置信的宽松！
锁定的一些例子包括现代语言，它们采用大小写约定并使其成为语言的强制部分（类的大写首字母等）——我相信 Ruby 至少会对此发出警告，而其他一些语言实际上会给出编译器错误，如果你（例如）以小写首字母命名类，或以大写首字母命名非类。我认为由此产生的强制一致性是一件好事，而且我不明白为什么它应该有所不同，因为样式的强制方面是间距而不是大小写等。IOW，阿诺德基本上说服了我这一点;-)。
Joel's Best Software Writing antology starts with Ken Arnold's interesting and provocative essay "Style is Substance", from Ken's post you can also read here. It's a well-argued essay with the thesis, and I quote, that "the only way to get from where we are to a place where we stop worrying about style is to enforce it as part of the language".
It's the only essay I've ever read that proposes that languages' compilers should lock down every aspect of style (your idea about locking down amount of indentation, for example, would be part of that -- not just in Python, either... Ken's main past contributions are Jini, curses, javaspaces, rogue, and parts of Corba, nothing Python-related). It makes really good points, and in the online version's comments you can see some counterpoints (alas, not necessarily equally well argued).
I do find it ironic that one responder talks about "Fortran and its strong formatting rules"; that sounds like somebody who never used Fortran, or used it with very shallow and marginal understanding of it. How many languages do you know where you can write, for example,
...? In Fortran, you can! The spaces are irrelevant, and ignored by the compiler, inside both identifiers and number literals, so you don't have to use underscores or camelcase to make multiword identifiers usable (just use spaces between words!) and it's easy to make large numbers readable too. Some languages did adopt this kind of rules, but most forbid spaces within identifiers and numbers.
Of course style flexibility always comes with risks of errors, e.g., in Fortran's case,
assigns to variable
DO10Ithe number 1.5, while the almost-undistinguishableloops five times on the block from here to line 10 (I believe a real-world occurrence of a bug like this one -- dot instead of comma drastically changing the code's meaning -- once damaged a space mission, but don't recall the exact details).
So, please don't take Fortran as an example either for or against "locking down", because in many stylistic aspects it's so incredibly loose instead!
Some examples of lockdown include modern languages that take e.g. case conventions and make them enforced parts of the language (uppercase initials for classes, etc) -- I believe Ruby at least warns about this and some other languages actually give compiler errors if you (e.g.) name a class with a lowercase initial or a non-class with an uppercase one. I think the resulting enforced uniformity is a good thing, and I don't see why it should be different where the enforced aspect of style is spacing rather than casing, etc. IOW, Arnold has mostly convinced me about this;-).
虽然要求单个块内的缩进一致会产生影响，但块之间的缩进级别相同或不同不会产生任何影响。换句话说，这有什么意义呢？
将其与空格要求进行比较实际上并不有效，因为空格是 Python 语法的一部分：它定义范围。只要范围可以明确定义，我们为什么要关心使用多少个空格来定义它呢？强迫每个人使用一些（完全任意的）固定数量的空间会带来什么好处？
如果您的文字处理程序强迫您将段落缩进正好四个空格怎么办？这会很烦人，而且没有任何作用。它不应该具有固定数量的缩进空间。
这样想吧：Python 没有“空白”要求，但它要求您找到一种方法来定义不带大括号的范围。其中掉下来的是空白，并且说它有一个“空白要求”比说它有一个“无大括号的范围定义”要求更容易和更明显，所以为了简洁沟通的目的，我们只是说它有一个“空白”要求' ;-）
While there are implications made by requiring consistent indentation within a single block, there are no implications made by having indentation levels between blocks be either the same or different. In other words, what would be the point?
Comparing it to the whitespace requirement isn't really valid because whitespace is a part of the syntax of Python: it defines scope. So long as scope can be unambiguously defined, why do we care how many spaces are used to define it? What benefit would be offered by forcing everyone to use some (completely arbitrary) fixed number of spaces?
What if your word processor forced you to indent paragraphs exactly four spaces? It would be annoying, and it would serve no purpose. It shouldn't serve a purpose to have a fixed number of spaces of indentation.
Think about it this way: Python doesn't have a 'whitespace' requirement so much as it has a requirement that you find a way to define scope without braces. What fell out of that was whitespace, and saying it has a 'whitespace requirement' is easier and more obvious than saying it has a 'scope definition sans braces' requirement, so for purposes of succinct communication, we just say it has a 'whitespace requirement' ;-)
Python 致力于快速原型设计。许多好的设计之所以有效，是因为大多数 Python 程序员都有良好的实践。这就是为什么我们不像 Java 那样依赖访问器和修改器，并且我们可以访问带有负数的数组索引。
在我看来，将空格限制为 4 个并禁止制表符并不能提高 Python 的可读性。长期以来，由于我们倡导的良好做法，很少出现问题。
我真的相信这一点。
Python 带来了便利。
Python is all about rapid prototyping. A lot of the good designs only work because most Python programmers have good practices. That's why we don't depend on accessors and mutators as much as Java, and we can access array indices with negative numbers.
In my opinion, limiting the whitespaces to 4 and disallowing tabs doesn't make Python more readable on a large-scale. For a long time, there has been very few issues, because of the good practices we advocate.
I truly believe it.
Python comes with convenience.
除了上面给出的原因之外，您希望解释器支持最小缩进的另一个非常好的理由是：节省空间。由于冻结 Python 字节码的限制，仅使用 .pyc 文件而不是实际代码来发布某些内容并不总是可行的。这意味着，如果您编写的代码要在空间非常有限的平台（例如 OpenWRT 路由器）上运行，那么将空间数量保持在最低限度以节省磁盘空间是很有意义的。
这就是为什么我写了 pyminifier
Beyond the reasons given above there's another really good reason why you'd want the interpreter to support minimal indentation: Saving space. Due to the limitations of freezing Python bytecode it isn't always practical to ship something with just .pyc files instead of the actual code. This means that if you're writing code to run on a a platform with very limited space (say, an OpenWRT router) it makes a lot of sense to keep the number of spaces to a minimum to save disk space.
This is why I wrote pyminifier
reindent.py 更改任何 python 文件以使用 4 - 空格缩进并且没有硬制表符。
有了这个方便的实用程序，就无需强迫其他人编程
4 空格风格的 Python。
附言。 Perl、Java、C 程序员花费很多脑力去处理分号语法错误。每个浪费在语法错误上的大脑周期都是一个没有花在解决真正的编程问题上的周期。 Python 快速开发的优势之一是它最大限度地减少了最终浪费脑力的语法规则。因此，语法要求越少越好。
reindent.py changes any python file to use 4-space indents and no hard tab characters.
Having this handy utility around obviates the need to force others to program
Python in the 4-space style.
PS. Perl, Java, C programmers spend many brain cycles fussing with semicolon syntax errors. Every brain cycle wasted on syntax fluff is a cycle not spend solving real programming problems. One of Python's advantages for rapid development is that it minimizes syntax rules that end up wasting brain cycles. Therefore fewer syntax requirements are better than more.
Python 与其他语言的不同之处在于空格和换行符非常重要。它是该语言的独特部分，当然使用起来非常干净，但我认为添加此限制会降低灵活性。
另外，我喜欢两个空格......我将被迫用两个空格编写程序，然后通过空格加倍器脚本运行它们作为编译步骤。
Python is already different than other languages in the way whitespace and line breaks are so significant. It's a unique part of the language and is very clean to work with of course, but I think to add this restriction would reduce flexibility.
Also, I like two spaces.... I'd be forced to write my programs with two spaces and then run them through a space doubler script as a compile step.
为了避免
make要求每个操作前面有制表符而出现的问题。例如，如果制表符等于四个空格，并且您在
.c文件和Makefile之间来回切换，那就很痛苦了To avoid the problems that occur with
make's requirement to have tab characters in-front of each action.For example It is a pain if you have tab equals four spaces and you're flicking back and forth from a
.cfile and aMakefile