我在Stack Overflow和PEP 8上看到，建议只在Python程序中使用空格用于缩进。我能理解保持一致的缩进的必要性，并且我已经感到了痛苦。

是否存在首选空间的根本原因？我本以为使用选项卡要容易得多。

解决方案

制表符的问题在于它们是不可见的，人们永远无法就制表符的宽度达成共识。当我们混合使用制表符和空格，并且将制表符设置为除Python之外的其他选项(每8个空格使用制表符)时，我们将看到的代码布局与Python看到的布局不同。并且由于布局确定了块，因此我们将看到不同的逻辑。它导致细微的错误。

如果我们坚持要违背PEP 8并使用制表符(或者更糟糕的是，混用制表符和空格)，则至少总是将python与'-tt'参数一起运行，这会导致缩进不一致(有时是制表符，有时是同一缩进级别的空格)一个错误。另外，如果可能，将编辑器设置为以不同方式显示选项卡。但实际上，最好的方法是不要使用制表符，句号。

制表符的普遍问题是，它们在不同的环境中可能以不同的方式表示。
在给定的编辑器中，选项卡可能是8个空格，也可能是2个空格。
在某些编辑器中，我们可以控制它，而在其他编辑器中，则不能控制。

制表符的另一个问题是它们在打印输出中的表示方式。我相信大多数打印机会将制表符解释为8个空格。

毫无疑问，有了空格。一切都会按照作者的意图排列。

对于制表符，我能说出的最显着的优势是，许多程序员和项目使用一定数量的列作为源代码，并且如果有人提交了自己的Tabstop设置为2的更改，而项目使用了4个空格制表符，对于其他人的编辑器窗口，长长的行将太长。我同意制表符更易于使用，但我认为空格更易于协作，这在像Python这样的大型开源项目中很重要。

由于python依靠缩进来识别程序结构，因此需要一种清晰的方法来识别标识。这就是选择空格或者制表符的原因。

但是，python也有一种很强的哲学，即只有一种方法可以做事，因此应该正式推荐一种缩进方法。

空格和制表符都给编辑人员处理缩进带来了独特的挑战。选项卡本身的处理在不同的编辑器甚至用户设置之间都不统一。由于空格是不可配置的，因此它们提供了更合乎逻辑的选择，因为它们可以保证结果在各个地方看起来都是相同的。

你可以吃蛋糕吃。设置编辑器以将选项卡自动展开为空格。

(在Vim中为：set expandtab。)

空格的原因是选项卡是可选的。在标点符号中，空格是实际的最小公分母。

每个体面的文本编辑器都有一个"用空格替换选项卡"，许多人都使用它。但不总是。

尽管某些文本编辑器可能会用制表符代替一排空格，但这确实很少见。

底线。空格绝对不会错。选项卡可能会出错。因此，请勿使用制表符，以减少发生错误的风险。

答案是在PEP中给出的[ed：此段落已在2013年被编辑]。我引用：

The most popular way of indenting Python is with spaces only.

我们还需要其他哪些根本原因？

坦率地说：也请考虑第一段中所述的PEP的范围：

This document gives coding conventions for the Python code comprising the standard library in the main Python distribution.

目的是使正式python发行版中的所有代码都保持一致的格式(我希望我们可以同意这普遍是一件好事吗？)。

由于对于单个程序员而言，空格和制表符之间的决定是a)确实是个问题，并且b)可以通过技术手段(编辑器，转换脚本等)轻松解决，因此有一种明确的方法可以结束所有讨论： 。

Guido是一个可供选择的人。他甚至不必给出理由，但他仍然通过引用经验数据来做到这一点。

出于所有其他目的，我们可以将此PEP作为建议，也可以忽略它-选择，团队或者团队领导者。

但是，如果我能给我们一个建议：请不要混合使用它们;-) [ed：不再将制表符和空格混合使用。]

问题的答案是：PEP-8希望提出建议，并决定由于空格更为流行，因此强烈建议在制表符上推荐空格。

关于PEP-8的注意事项

PEP-8说："每个缩进级别使用4个空格。"
很明显，这是标准建议。

"对于不想弄乱的真正旧代码，我们可以继续使用8位制表符。"
很明显，在某些情况下可以使用制表符。

"切勿将制表符和空格混在一起。"
这是明确禁止混用的，我想我们都同意这一点。 Python可以检测到这一点，并且经常使人感到窒息。使用-tt参数使它成为一个显式错误。

'缩进Python的最流行方法是仅使用空格。第二受欢迎的方式是仅使用制表符。"
这清楚地表明两者都被使用了。只是要非常清楚：我们仍然不应该在同一文件中混用空格和制表符。

"对于新项目，强烈建议在选项卡上仅使用空格。"
这是一个明确的建议，是一项强有力的建议，但不是禁止使用制表符的建议。

我在PEP-8中找不到自己的问题的好答案。
我使用的标签是我以前在其他语言中使用过的标签。
Python接受使用制表符专用的源代码。对我来说足够了。

我以为我会尝试使用空间。在编辑器中，我将文件类型配置为仅使用空格，因此如果按Tab键，它将插入4个空格。如果按Tab键太多次，则必须删除空格！啊！删除次数是标签页的四倍！我的编辑器无法告诉我正在使用4个缩进空格(尽管AN编辑器可以执行此操作)，并且显然坚持每次删除一个空格。

难道不让Python在读取缩进时将制表符考虑为n个空格吗？
如果我们可以同意每个缩进4个空格和每个制表符4个空格并允许Python接受，那么就不会有问题。
我们应该找到双赢的解决方案。

混合制表符和空格时会出现缩进的主要问题。显然，这并不能告诉我们应该选择哪一种，但这是推荐一个很好的理由，即使我们是通过掷硬币来挑选它的。

但是，恕我直言，有一些次要的理由倾向于使用空格而不是制表符：

• 不同的工具。有时代码会显示在程序员的编辑器之外。例如。发布到新闻组或者论坛。在这里，空格通常比制表符更好-到处都会弄乱空格，制表符也是如此，但反之则不然。
• 程序员对源代码的看法有所不同。这是非常主观的-它可能是制表符的主要优点，还是根据我们所站在的那一侧来避免使用它们的原因。从好的方面来说，开发人员可以使用首选缩进方式查看源代码，因此更喜欢2空间缩进的开发人员可以与8空间开发人员在同一个源代码上一起工作，并且仍然可以随意查看它们。不利的一面是，这给人带来了影响-有些人喜欢8空格，因为它提供了非常明显的嵌套嵌套的非常明显的反馈-他们可能会看到2-indenter检入的代码不断地包裹在编辑器中。让每个开发人员以相同的方式查看代码将导致行长度的一致性更高，以及其他一些问题。
• 续行缩进。有时我们希望缩进一行以指示它是从上一行开始的。例如。

def foo():
    x = some_function_with_lots_of_args(foo, bar, baz,
                                        xyzzy, blah)

如果使用制表符，则无法在不混用空格和制表符的情况下，针对在编辑器中使用不同制表符的人们进行调整。这有效地扼杀了上述好处。

但是，显然，这是一个深深的宗教问题，编程受到困扰。最重要的问题是，即使不是我们最喜欢的那个，我们也应该选择一个。有时，我认为显着缩进的最大优势在于，至少我们没有幸免放置牙套。

杰米·扎温斯基(Jamie Zawinski)撰写的有关该问题的这篇文章也值得一读。

JWZ最好地说：

When [people are] reading code, and when they're done writing new code, they care about how many screen columns by which the code tends to indent when a new scope (or sexpr, or whatever) opens...
  
  ...My opinion is that the best way to solve the technical issues is to mandate that the ASCII #9 TAB character never appear in disk files: program your editor to expand TABs to an appropriate number of spaces before writing the lines to disk...
  
  ...This assumes that you never use tabs in places where they are actually significant, like in string or character constants, but I never do that: when it matters that it is a tab, I always use '\t' instead.

我个人不同意制表符上的空格。对我而言，制表符是文档布局的字符/机制，而在代码情况下，空格用于表示命令之间的内容或者命令之间的轮廓。

我必须同意吉姆(Jim)的评论，即制表符并不是真正的问题，这是人们以及他们希望如何混合使用制表符和空格。

就是说，为了惯例起见，我强迫自己使用空格。我重视一致性而不是个人喜好。