【问题标题】:Why doesn't Python require exactly four spaces per indentation level?为什么 Python 不需要每个缩进级别正好四个空格?
【发布时间】:2010-06-03 13:19:09
【问题描述】:

空格在 Python 中的意义在于代码块由它们的缩进定义。

此外,Guido van Rossum 建议每个缩进级别使用四个空格(请参阅PEP 8: Style Guide for Python Code)。

每个缩进级别也不需要恰好四个空格的原因是什么?有什么技术原因吗?

似乎所有可用于使空白定义代码块的参数也可用于为一个缩进级别(例如四个空格)设置确切的空白长度的参数。

【问题讨论】:

  • 为什么要限制? Python 从来都不是限制程序员的语言。
  • Xavier:这不是 Perl 的论据吗? :-) 来自“The Zen of Python”:“应该有一种——最好只有一种——明显的方法。”
  • cmets 没有反对票,所以我会说:) 我的梦想不仅是四个空格的要求,还要求命名functions_in_lower_casePascalCase 中的类等。支持特殊情况,例如 from __legacy__ import anynames 可能存在。
  • 像我们这样喜欢tab的草皮怎么办?!
  • @knorv:Python 喜欢直觉和可读性。发现干净的代码,就像设计模式一样。他们很高兴知道,但没有强制执行。 Python 的设计有助于实现这一点——即尽可能保持一致。但我现在要发布一个快速答案。

标签: python indentation


【解决方案1】:

没有技术原因。将 Python 解释器修改为每个缩进级别恰好需要四个空格并不难。

这是其他缩进级别的一个用例:在交互式解释器中键入时,使用一个空格缩进非常方便。它节省了打字时间,更容易正确计算空格数,并且可读性不是主要问题(因为代码甚至没有保存在文件中)。

【讨论】:

    【解决方案2】:

    我刚刚在tutor@python.org 邮件列表上遇到的另一个案例——一个在Python 中工作的盲人程序员使用了一个阅读器程序——显然阅读器程序不是很喜欢多个空格,所以对他来说更容易使用单个空格。

    确实没有好的或技术上的理由要求恰好 4 个空格,我认为反对 要求 的最佳论据是程序员讨厌受到限制,尤其是受到愚蠢和有些武断的规则的限制。当然,我们都同意 4 个空格是最好的,而且我们大多数人都有编辑器自动设置我们的缩进,但是在某些情况下你不想使用 4 个空格 - 一个关闭脚本代码等 - 你现在疏远了一个感觉任意(风格)要求的粉碎之手。

    对于大多数人来说,空格的重要性不是问题,原因有几个。首先,我想不出一个(好)程序员会认为正确的代码格式是一件坏事。其次,逻辑要求我们将代码分成块。许多语言使用 {} 分隔符。在组装中,它通常是标签。 Python 对空格的选择实际上是相当自然的,至少对于英语来说是这样。当你阅读一本书、一份报纸或一篇博客文章时,当有人引用它时,它通常是缩进的。段落由一个或两个空行分隔。章节通常由一页末尾的空格和下一页开头的空格分隔。所以空白是一件好事,但强迫程序员遵守你的特定标准会让程序员用他们的时间去做其他事情。

    【讨论】:

    • 如果 Python 需要 4 个空格(或 7 个,或其他),我们甚至不需要这个讨论。因此,通过强加一种语言风格来避免风格讨论是一件好事。正如你所说:一个 apt 程序员可以阅读 7 个空格缩进的代码以及 4 个空格缩进的代码,所以为什么不强制每个人都使用 4?
    • 我从没想过这个问题。他/她是否编写了一个脚本来将 4 空格缩进转换为 1 空格缩进,等等?我想听到“space space sapce space def class...”会很烦人。
    • @Xavier:是的,他确实这样做了——不过我不记得是脚本还是他只是使用了编辑器功能。
    • 很高兴听到这样的故事。我记得 SO 上的另一位成员因为手指疼痛而无法打字,所以他使用并训练了 Dragon NaturallySpeaking 来进行编码。显然,它的工作非常顺利。
    • @Xavier:我总是喜欢听到那些被认为是“残疾人”的人在他们的身体/精神限制下工作,以享受我们许多人认为理所当然的活动。如果我最终进入学术界,我相信我会专注于该领域的大量研究。
    【解决方案3】:
    【解决方案4】:

    在打代码时使用 1 个空格(或制表符)可以节省空间:-p

    【讨论】:

      【解决方案5】:

      Joel 的Best Software Writing antology 以 Ken Arnold 有趣且具有挑衅性的文章“Style is Substance”开头,从 Ken 的帖子中您也可以阅读 here。这是一篇论证充分的论文,我引用了这篇论文,“从我们所处的位置到我们不再担心风格的地方的唯一方法是将其作为语言的一部分来强制执行”。

      这是我读过的唯一一篇建议语言的编译器应该锁定样式的每个方面的文章(例如,你关于锁定缩进量的想法就是其中的一部分-- 也不只是在 Python 中……Ken 过去的主要贡献是 Jini、curses、javaspaces、rogue 和 Corba 的一部分,与 Python 无关)。它提出了非常好的观点,并且在在线版本的 cmets 中,您可以看到一些对位(唉,不一定有同样的论点)。

      一位回复者谈到“Fortran 及其强大的格式规则”,我确实觉得很讽刺;这听起来像是一个从未使用过 Fortran 的人,或者对它的理解非常肤浅和边缘化的人。例如,您知道多少种语言可以在哪里写作,

      total count = 1 000 000
      

      ...?在 Fortran 中,您可以!在标识符和数字文字中,空格是无关紧要的,并且会被编译器忽略,因此您不必使用下划线或驼峰式来使多字标识符可用(只需在单词之间使用空格!)并且很容易使大数字可读也。一些语言确实采用了这种规则,但大多数禁止标识符和数字中的空格。

      当然,样式灵活性总是伴随着错误的风险,例如,在 Fortran 的情况下,

      DO 10 I = 1. 5
      

      将数字 1.5 分配给变量 DO10I,而几乎无法区分

      DO 10 I = 1, 5
      

      在从这里到第 10 行的块上循环五次(我相信现实世界中会出现像这样的错误 - 点而不是逗号会极大地改变代码的含义 - 一旦损坏了太空任务,但不要'不记得确切的细节)。

      因此,无论是支持还是反对“锁定”,请不要以 Fortran 为例,因为在许多文体方面它是如此令人难以置信的宽松

      锁定的一些示例包括现代语言,例如大小写约定并使它们强制成为语言的一部分(类的大写首字母等)——我相信 Ruby 至少会警告这一点,如果你(例如)用小写首字母或大写的非类。我认为由此产生的强制统一性是一件好事,我不明白为什么在风格的强制方面是间距而不是大小写等方面应该有所不同。IOW,Arnold 基本上让我相信这一点;-)。

      【讨论】:

      • stackoverflow.com/questions/1740116/… 中,您雄辩地反对区分大小写。那么,您是否更喜欢 Python 具有样式锁定,该样式是全大写(或全小写)?
      • @unutbu,在实践中,我确实必须以特定的大写风格进行编程(在工作中:我们拥有并执行风格指南),虽然我不会发现所有大写字母都更具可读性与早期的 Fortran 相比,lowercase_with_underscores 我会发现比 CamelCaseStuff(这是 Google 的类和函数风格)更可取。当然,这一切都是假设性的;-)。
      【解决方案6】:

      虽然要求单个块内的缩进一致会产生影响,但没有块之间的缩进级别相同或不同会产生影响。换句话说,重点是什么?

      将其与空格要求进行比较并不是真正有效的,因为空格是 Python 语法的一部分:它定义了范围。只要范围可以明确定义,我们为什么要关心使用多少空格来定义它?强迫每个人使用一些(完全任意的)固定数量的空间会带来什么好处?

      如果您的文字处理器强制您将段落缩进四个空格怎么办?这会很烦人,而且毫无用处。 不应该具有固定数量的缩进空间。

      这样想:Python 没有“空白”要求,而是要求您找到一种方法来定义没有大括号的范围。从中得出的是空白,并且说它具有“空白要求”比说它具有“范围定义无括号”要求更容易和更明显,因此为了简洁的交流,我们只是说它具有“空白”要求';-)

      【讨论】:

        【解决方案7】:

        Python 是关于快速原型设计的。许多好的设计之所以能奏效,是因为大多数 Python 程序员都有良好的实践。这就是为什么我们不像 Java 那样依赖访问器和修改器,而且我们可以使用负数访问数组索引。

        在我看来,将空格限制为 4 个并禁止使用制表符并不会让 Python 在大规模上更具可读性。长期以来,由于我们倡导的良好做法,很少出现问题。

        我真的相信。

        Python 带来了便利。

        【讨论】:

          【解决方案8】:

          除了上面给出的原因之外,还有一个很好的理由让解释器支持最小缩进:节省空间。由于冻结 Python 字节码的局限性,仅使用 .pyc 文件而不是实际代码来发布某些东西并不总是可行的。这意味着,如果您正在编写代码以在空间非常有限的平台(例如,OpenWRT 路由器)上运行,那么将空间数量保持在最低限度以节省磁盘空间是很有意义的。

          这就是我写pyminifier的原因

          【讨论】:

            【解决方案9】:

            reindent.py 将任何 python 文件更改为使用 4 空格缩进并且没有硬制表符。 拥有这个方便的实用程序可以避免强迫其他人编程 4 空格样式的 Python。

            PS。 Perl、Java、C 程序员花费很多脑力来处理分号语法错误。浪费在语法绒毛上的每个大脑周期都是一个没有用于解决实际编程问题的周期。 Python 在快速开发方面的优势之一是它最大限度地减少了最终浪费大脑周期的语法规则。因此,语法要求越少越好。

            【讨论】:

            • 我不确定我是否遵循您的回答。如果您将文件重新缩进为 4 空格缩进,实际上您确实会强迫人们在使用 4 空格缩进之后查看源代码......除非您在提交之前将其更改回来。
            • @viraptor:有一些工具(如unexpand)可以将空格转换为制表符。因此,如果有人真的想使用制表符缩进的 python,他们也有办法这样做。
            【解决方案10】:

            在空格和换行符的重要性方面,Python 已经不同于其他语言。这是语言的一个独特部分,当然使用起来非常干净,但我认为添加这个限制会降低灵活性。

            另外,我喜欢两个空格....我不得不用两个空格编写我的程序,然后通过空格倍增器脚本作为编译步骤运行它们。

            【讨论】:

              【解决方案11】:

              为了避免make 要求在每个操作前面有制表符时出现的问题。

              例如,如果您的制表符等于四个空格,并且您在 .c 文件和 Makefile 文件中来回滑动,这会很痛苦

              【讨论】:

                猜你喜欢
                • 1970-01-01
                • 1970-01-01
                • 2010-11-10
                • 2018-08-28
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 2013-11-09
                • 2017-07-04
                相关资源
                最近更新 更多