为什么Python pep-8强烈建议在制表符上使用空格来缩进?

问题:为什么Python pep-8强烈建议在制表符上使用空格来缩进?

我在Stack Overflow和PEP 8上看到,建议是仅将空格用于Python程序中的缩进。我能理解保持一致的缩进的必要性,我已经感到痛苦。

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

I see on Stack Overflow and PEP 8 that the recommendation is to use spaces only for indentation in Python programs. I can understand the need for consistent indentation and I have felt that pain.

Is there an underlying reason for spaces to be preferred? I would have thought that tabs were far easier to work with.


回答 0

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

缩进Python 的最流行方法是仅使用空格。

您还需要其他哪些根本原因?

坦率地说:如第一段所述,还要考虑PEP的范围:

本文档给出了Python代码的编码约定,该Python代码包含主Python发行版中的标准库。

目的是使正式python发行版本中的所有代码都保持一致的格式(我希望我们可以同意这是普遍适用的Good Thing™)。

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

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

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

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

The answer was given right there in the PEP [ed: this passage has been edited out in 2013]. I quote:

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

What other underlying reason do you need?

To put it less bluntly: Consider also the scope of the PEP as stated in the very first paragraph:

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

The intention is to make all code that goes in the official python distribution consistently formatted (I hope we can agree that this is universally a Good Thing™).

Since the decision between spaces and tabs for an individual programmer is a) really a matter of taste and b) easily dealt with by technical means (editors, conversion scripts, etc.), there is a clear way to end all discussion: choose one.

Guido was the one to choose. He didn’t even have to give a reason, but he still did by referring to empirical data.

For all other purposes you can either take this PEP as a recommendation, or you can ignore it — your choice, or your team’s, or your team leaders.

But if I may give you one advice: don’t mix’em ;-) [ed: Mixing tabs and spaces is no longer an option.]


回答 1

好吧,似乎每个人都强烈偏爱空间。我专门使用制表符。我很清楚为什么。

标签实际上是一个很酷的发明,来到空格。它使您可以缩进而无需数百万次按空格或使用伪造的制表符(产生空格)。

我真的不明白为什么每个人都在区别使用制表符。这很像老年人歧视年轻人,因为他们选择了更新的更有效的技术,并且抱怨脉冲拨号在每部电话都有效不仅在这些花哨的新。“音调拨号并非在所有电话上都有效,这就是为什么它是错误的”。

您的编辑器无法正确处理标签?好吧,请一位现代编辑。也许该死的时代,我们现在处于21世纪,而编辑器是高科技复杂软件的时代已经过去很久了。现在,我们有无数的编辑者可供选择,所有这些人都支持选项卡。另外,您可以定义制表符应该有多少,而空格则无法做到。看不到标签?那是什么意思呢?好吧,您也看不到空格!

我可以这么大胆地建议找一个更好的编辑器吗?这些高科技产品之一,已经在10年前发布了,它们显示了看不见的字符?(嘲讽)

使用空格会导致更多的删除和格式化工作。这就是为什么(以及所有其他知道这一点并同意我的人)使用Python的选项卡的原因。

制表符和空格的混合是不行的,对此也不存在任何参数。那是一团糟,永远无法正常工作。

Well well, seems like everybody is strongly biased towards spaces. I use tabs exclusively. I know very well why.

Tabs are actually a cool invention, that came after spaces. It allows you to indent without pushing space millions of times or using a fake tab (that produces spaces).

I really don’t get why everybody is discriminating the use of tabs. It is very much like old people discriminating younger people for choosing a newer more efficient technology and complaining that pulse dialing works on every phone, not just on these fancy new ones. “Tone dialing doesn’t work on every phone, that’s why it is wrong”.

Your editor cannot handle tabs properly? Well, get a modern editor. Might be darn time, we are now in the 21st century and the time when an editor was a high tech complicated piece of software is long past. We have now tons and tons of editors to choose from, all of them that support tabs just fine. Also, you can define how much a tab should be, a thing that you cannot do with spaces. Cannot see tabs? What is that for an argument? Well, you cannot see spaces neither!

May I be so bold to suggest to get a better editor? One of these high tech ones, that were released some 10 years ago already, that display invisible characters? (sarcasm off)

Using spaces causes a lot more deleting and formatting work. That is why (and all other people that know this and agree with me) use tabs for Python.

Mixing tabs and spaces is a no-no and no argument about that. That is a mess and can never work.


回答 2

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

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

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

I personally don’t agree with spaces over tabs. To me, tabs are a document layout character/mechanism while spaces are for content or delineation between commands in the case of code.

I have to agree with Jim’s comments that tabs aren’t really the issue, it is people and how they want to mix tabs and spaces.

That said, I’ve forced myself to use spaces for the sake of convention. I value consistency over personal preference.


回答 3

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

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

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

底线。空格绝对不会出错。你可能会出差错的标签。因此,请勿使用制表符,以减少出错的风险。

The reason for spaces is that tabs are optional. Spaces are the actual lowest-common denominator in punctuation.

Every decent text editor has a “replace tabs with spaces” and many people use this. But not always.

While some text editors might replace a run of spaces with a tab, this is really rare.

Bottom Line. You can’t go wrong with spaces. You might go wrong with tabs. So don’t use tabs and reduce the risk of mistakes.


回答 4

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

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

The problem with tabs is that they are invisible, and people can never agree on the width of tabs. When you mix tabs and spaces, and you set tabstops at something other than Python (which uses tabstops every 8 spaces) you will be seeing the code in a different layout than Python sees it. And because the layout determines blocks, you will be seeing different logic. It leads to subtle bugs.

If you insist on defying PEP 8 and using tabs — or worse, mixing tabs and spaces — at least always run python with the ‘-tt’ argument, which makes inconsistent indentation (sometimes a tab, sometimes a space for the same indentation level) an error. Also, if possible, set your editor to display tabs differently. But really, the best approach is not to use tabs, period.


回答 5

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

但是,恕我直言,有一些较小的理由偏爱制表符而不是制表符:

  • 不同的工具。有时代码会显示在程序员的编辑器之外。例如。发布到新闻组或论坛。在这里,空格通常比制表符更好-到处都会弄乱空格,制表符也是如此,但反之则不然。

  • 程序员对源代码的看法有所不同。这是非常主观的-它要么是制表符的主要优点,要么是根据您所站在的那一侧来避免使用它们的原因。从好的方面来说,开发人员可以使用首选缩进方式查看源代码,因此更喜欢2空间缩进的开发人员可以与8空间开发人员在同一源代码上一起工作,并且仍然可以随意查看它们。不利的一面是,这给人带来了影响-有些人喜欢8空格,因为它提供了非常明显的嵌套嵌套的非常明显的反馈-他们可能会看到2-indenter检入的代码不断地包裹在编辑器中。让每个开发人员以相同的方式查看代码将导致行长度的一致性更高,以及其他一些问题。

  • 续行缩进。有时您希望缩进一行以指示它是从上一行开始的。例如。

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

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

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

同样值得一读的是杰米·扎温斯基(Jamie Zawinski )的这篇文章。

The main problems with indentation occur when you mix tabs and spaces. Obviously this doesn’t tell you which you should choose, but it is a good reason to to recommend one, even if you pick it by flipping a coin.

However, IMHO there are a few minor reasons to favour spaces over tabs:

  • Different tools. Sometimes code gets displayed outside of a programmer’s editor. Eg. posted to a newsgroup or forum. Spaces generally do better than tabs here – everywhere spaces would get mangled, tabs do as well, but not vice-versa.

  • Programmers see the source differently. This is deeply subjective – its either the main benefit of tabs, or a reason to avoid them depending on which side you’re on. On the plus side, developers can view the source with their preferred indentation, so a developer preferring 2-space indent can work with an 8-space developer on the same source and still see it as they like. The downside is that there are repercussions to this – some people like 8-space because it gives very visible feedback that they’re too deeply nested – they may see code checked in by the 2-indenter constantly wrapping in their editor. Having every developer see the code the same way leads to more consistency wrt line lengths, and other matters too.

  • Continued line indentation. Sometimes you want to indent a line to indicate it is carried from the previous one. eg.

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

    If using tabs, theres no way to align this for people using different tabstops in their editor without mixing spaces and tabs. This effectively kills the above benefit.

Obviously though, this is a deeply religious issue, which programming is plagued with. The most important issue is that we should choose one – even if thats not the one you favour. Sometimes I think that the biggest advantage of significant indentation is that at least we’re spared brace placement flamewars.

Also worth reading is this article by Jamie Zawinski on the issue.


回答 6

请注意,使用制表符会混淆PEP 8的另一方面:

限制所有行最多79个字符。

假设,假设您使用2的制表符宽度,而我使用8的制表符宽度。编写所有代码,以使最长行达到79个字符,然后我开始处理文件。现在,我有一些难以阅读的代码,因为(如PEP所述):

大多数工具中的默认包装会破坏代码的视觉结构

如果我们都使用4个空格,那就总是一样。编辑器可以支持80个字符的宽度的任何人都可以轻松阅读代码。注意:80个字符的限制本身就是一场神圣的战争,因此,我们不要从这里开始。

任何不精简的编辑器都应该有一个使用空格的选项,就好像它们是制表符一样(插入和删除),因此实际上不应是有效的参数。

Note that the use of tabs confuses another aspect of PEP 8:

Limit all lines to a maximum of 79 characters.

Let’s say, hypothetically, that you use a tab width of 2 and I use a tab width of 8. You write all your code so your longest lines reach 79 characters, then I start to work on your file. Now I’ve got hard-to-read code because (as the PEP states):

The default wrapping in most tools disrupts the visual structure of the code

If we all use 4 spaces, it’s ALWAYS the same. Anyone whose editor can support an 80 character width can comfortably read the code. Note: The 80 character limit is a holy war in and of itself, so let’s not start that here.

Any non-sucky editor should have an option to use spaces as if they were tabs (both inserting and deleting), so that really shouldn’t be a valid argument.


回答 7

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


关于PEP-8的注意事项

PEP-8说:“每个缩进级别使用4个空格。”
很明显,这是标准建议。

“对于不想弄乱的真正旧代码,您可以继续使用8位制表符。”
很明显,在某些情况下可以使用选项卡。

“切勿混用制表符和空格。”
明确禁止混用-我认为我们都对此表示同意。Python可以检测到这一点,并且经常使人窒息。使用-tt参数使它成为显式错误。

‘缩进Python的最流行方法是仅使用空格。第二流行的方式是仅使用标签。
这清楚地表明两者都被使用。只是要非常清楚:您仍不应在同一文件中混用空格和制表符。

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


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

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

难道不建议Python在读取缩进时将制表符视为n个空格吗?如果我们可以同意每个缩进4个空格和每个制表符4个空格并允许Python接受,则不会有问题。
我们应该找到双赢的解决方案。

The answer to the question is: PEP-8 wants to make a recommendation and has decided that since spaces are more popular it will strongly recommend spaces over tabs.


Notes on PEP-8

PEP-8 says ‘Use 4 spaces per indentation level.’
Its clear that this is the standard recommendation.

‘For really old code that you don’t want to mess up, you can continue to use 8-space tabs.’
Its clear that there are SOME circumstances when tabs can be used.

‘Never mix tabs and spaces.’
This is a clear prohibition of mixing – I think we all agree on this. Python can detect this and often chokes. Using the -tt argument makes this an explicit error.

‘The most popular way of indenting Python is with spaces only. The second-most popular way is with tabs only.’
This clearly states that both are used. Just to be ultra-clear: You should still never mix spaces and tabs in same file.

‘For new projects, spaces-only are strongly recommended over tabs.’
This is a clear recommendation, and a strong one, but not a prohibition of tabs.


I can’t find a good answer to my own question in PEP-8. I use tabs, which I have used historically in other languages. Python accepts source with exclusive use of tabs. That’s good enough for me.

I thought I would have a go at working with spaces. In my editor, I configured a file type to use spaces exclusively and so it inserts 4 spaces if I press tab. If I press tab too many times, I have to delete the spaces! Arrgh! Four times as many deletes as tabs! My editor can’t tell that I’m using 4 spaces for indents (although AN editor might be able to do this) and obviously insists on deleting the spaces one at a time.

Couldn’t Python be told to consider tabs to be n spaces when its reading indentations? If we could agree on 4 spaces per indentation and 4 spaces per tab and allow Python to accept this, then there would be no problems.
We should find win-win solutions to problems.


回答 8

我一直在代码中使用制表符。就是说,我最近找到了使用空格的理由:在诺基亚N900互联网平板电脑上进行开发时,我现在有了一个没有Tab键的键盘。这迫使我要么复制和粘贴选项卡,要么用空格重写我的代码。我在其他手机上也遇到了同样的问题。当然,这不是Python的标准用法,但需要牢记。

I’ve always used tabs in my code. That said, I’ve recently found a reason to use spaces: When developing on my Nokia N900 internet tablet, I now had a keyboard without a tab key. This forced me to either copy and paste tabs or re-write my code with spaces. I’ve run into the same problem with other phones. Granted, this is not a standard use of Python, but something to keep in mind.


回答 9

JWZ说得最好

当[人们]正在阅读代码时,当他们写完新代码时,他们会在打开新的作用域(或sexpr或其他东西)时关心代码倾向于缩进多少屏幕列…

…我的观点是,解决技术问题的最佳方法是强制要求ASCII#9 TAB字符永远不会出现在磁盘文件中:对编辑器进行编程,以将TAB扩展到适当数量的空格,然后再将行写入磁盘。 ..

…这假设您从未在制表符真正重要的地方使用过制表符,例如在字符串或字符常量中,但是我从不这样做:当重要的是制表符时,我总是使用’​​\ t’代替。

JWZ says it best:

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.


回答 10

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

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

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

Since python relies on indentation in order to recognize program structure, a clear way to identify identation is required. This is the reason to pick either spaces or tabs.

However, python also has a strong philosophy of only having one way to do things, therefore there should be an official recommendation for one way to do indentation.

Both spaces and tabs pose unique challenges for an editor to handle as indentation. The handling of tabs themselves is not uniform across editors or even user settings. Since spaces are not configurable, they pose the more logical choice as they guarantee that the outcome will look everywhere the same.


回答 11

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

The most significant advantage I can tell of spaces over tabs is that a lot of programmers and projects use a set number of columns for the source code, and if someone commits a change with their tabstop set to 2 spaces and the project uses 4 spaces as the tabstop the long lines are going to be too long for other people’s editor window. I agree that tabs are easier to work with but I think spaces are easier for collaboration, which is important on a large open source project like Python.


回答 12

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

:set expandtab在Vim中。)

You can have your cake and eat it to. Set your editor to expand tabs into spaces automatically.

(That would be :set expandtab in Vim.)


回答 13

我的猜测是,大多数linux文本编辑器默认情况下都会使默认值看起来大得离谱。我想不出其他理由来在制表符上使用空格。

My guess is that most the linux text editors make defaults look ridiculously large by default. I can’t think of any other good reason to use spaces over tabs.


回答 14

除了已经命名的所有其他原因(一致性,不要混用空格和制表符等)之外,我相信还有其他一些理由可以说明这4个空格约定。这些仅适用于Python(可能还有缩进有意义的其他语言)。根据个人喜好,其他语言的选项卡可能更好。

  1. 如果编辑器没有显示选项卡(根据配置的不同,发生的次数很多),那么另一位作者可能会假设您的代码使用4个空格,几乎所有可公开获得的Python代码都会使用4个空格。如果同一编辑器的制表符宽度为4,则可能会发生令人讨厌的事情-至少,那个穷人会因为遵循惯例而很容易避免的缩进问题而浪费时间。因此,对我而言,首要原因是避免具有一致性的错误。

  2. 回顾制表符或空格中哪个更好的问题,应该问一下制表符的优点是什么;我见过很多赞美标签的帖子,但很少有令人信服的论点。emacs,vi(m),kate等优秀的编辑器会根据您代码的语义进行适当的缩进-即使没有制表符也是如此;可以轻松地将相同的编辑器配置为在退格键等上缩进。

  3. 在决定代码的外观/布局的自由方面,有些人有很强的偏好。其他人则重视这种自由的一致性。Python通过指示将缩进用于块等来极大地降低了这种自由度。这可能被视为错误或功能,但选择Python会带来一些麻烦。就个人而言,我喜欢这种一致性-在开始为新项目进行编码时,至少布局与我惯用的布局非常接近,因此相当容易阅读。几乎总是。

  4. 使用空格进行缩进允许“布局技巧”,这些技巧可能有助于理解代码。PEP8中列出了其中一些示例;例如。

    foo = long_function_name(var_one, var_two,
                             var_three, var_four)
    
    # the same for lists
    a_long_list = [1,
                   2,
                   # ...
                   79]
    
    # or dictionaries
    a_dict = {"a_key": "a_value",
              "another_key": "another_value"}

    当然,以上内容也可以写得很好

    foo = long_function_name(
        var_one, var_two,
        var_three, var_four)
    
    # the same for lists
    a_long_list = [
        1,
        2,
        # ...
        79]
    
    # or dictionaries
    a_dict = {
        "a_key": "a_value",
        "another_key": "another_value"}

    但是,后者占用了更多的代码行,并且有时认为更少的行会更好(b / c您可以在一个屏幕上得到更多)。但是,如果您喜欢对齐,则从某种意义上说,空格(最好由一个好的编辑器协助)在Python中为您提供了比制表符更多的自由度。[好吧,我猜有些编辑器允许您使用制表符执行相同的操作;)-但如果有空格,所有的编辑器都可以执行…]

  5. 回到其他人都提出的相同论点-PEP 8指示(好的,强烈建议)空格。当然,如果来到仅使用选项卡的项目,则别无选择。但是由于建立了PEP 8约定,几乎所有Python程序员都习惯了这种样式。这使得在大多数程序员都能接受的风格上达成共识变得容易得多,否则让个人对风格达成共识可能很难。

  6. 通常,帮助执行样式的工具无需费力即可了解PEP 8。这不是一个很好的理由,但是开箱即用就可以了。

Besides all the other reasons already named (consistency, never mixing spaces and tabs etc) I believe there are a few more reasons for the 4 spaces convention to note. These only apply to Python (and maybe other languages where indentation has meaning). Tabs may be nicer in other languages, depending on individual preferences.

  1. If an editor doesn’t show tabs (which happens, depending on the configuration, in quite a few), another author might assume that your code uses 4 spaces, b/c almost all of the Python code being publicly available does; if that same editor happens to have a tab width of 4, nasty things may happen – at least, that poor person will lose time over an indentation issue that would have been very easy to avoid by sticking to the convention. So for me, the number one reason is to avoid bugs with consistency.

  2. Reframing the question of which is better, tabs or spaces, one should ask which the advantages of tabs are; I’ve seen plenty posts praising tabs, but few compelling arguments for them; good editors like emacs, vi(m), kate, … do proper indentation depending on the semantics of your code – even without tabs; the same editors can easily be configured to unindent on backspace etc.

  3. Some people have very strong preferences when it comes to their freedom in deciding the look/ layout of code; others value consistency over this freedom. Python drastically reduces this freedom by dictating that indentation is used for blocks etc. This may be seen as a bug or a feature, but it sort of comes with choosing Python. Personally, I like this consistency – when starting to code on a new project, at least the layout is close to what I’m used to, so it’s fairly easy to read. Almost always.

  4. Using spaces for indentation allows “layout tricks” that may facilitate to comprehend code; some examples of these are listed in PEP8; eg.

    foo = long_function_name(var_one, var_two,
                             var_three, var_four)
    
    # the same for lists
    a_long_list = [1,
                   2,
                   # ...
                   79]
    
    # or dictionaries
    a_dict = {"a_key": "a_value",
              "another_key": "another_value"}
    

    Of course, the above can also be written nicely as

    foo = long_function_name(
        var_one, var_two,
        var_three, var_four)
    
    # the same for lists
    a_long_list = [
        1,
        2,
        # ...
        79]
    
    # or dictionaries
    a_dict = {
        "a_key": "a_value",
        "another_key": "another_value"}
    

    However, the latter takes more lines of code and less lines are sometimes argued to be better (b/c you get more on a single screen). But if you like alignment, spaces (preferably assisted by a good editor) give you, in a sense, more freedom in Python than tabs. [Well, I guess some editors allow you to do the same w/ tabs ;) – but with spaces, all of them do…]

  5. Coming back to the same argument that everybody else makes – PEP 8 dictates (ok, strongly recommends) spaces. If coming to a project that uses tabs only, of course, you have little choice. But because of the establishment of the PEP 8 conventions, almost all Python programmers are used to this style. This makes it sooooo much easier to find a consensus on a style that is accepted by most programmers… and having individuals agree on style might be very hard otherwise.

  6. Tools that help enforcing style are usually aware of PEP 8 without extra effort. That’s not a great reason, but it’s just nice to have things work ~out of the box.


回答 15

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

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

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

The universal problem with tabs is that they can be represented differently in different environment.
In a given editor, a tab might be 8 spaces or it might be 2.
In some editors, you can control this, while in others you can’t.

Another issue with tabs is how they are represented in printed output. I believe most printers interpret a tab as 8 spaces.

With spaces, there is no doubt. Everything will line up as the author intended.


回答 16

关于Jim和Thomas Wouters之间的讨论

问题是…因为制表符和空格的宽度都可以变化-并且由于程序员不能在这两个宽度上达成共识-为什么制表符要怪罪。

我同意吉姆的观点-制表符本身并不邪恶。但有个问题…

使用空格,我可以控制“我自己的代码” 世界上每个编辑器中外观。如果我使用4个空格-则无论您在哪个编辑器中打开我的代码,它与左边距的距离都是相同的。使用标签时,我受制于编辑器的标签宽度设置-甚至对于我自己的代码也是如此。我不喜欢那样

因此,即使空格不能保证一致性也确实如此-它们至少使您可以更好地控制OWN代码的外观-制表符无法做到。

我认为,这并不是使程序员更容易实现(并强加)空格的方法,而是程序员编写代码的一致性,而是显示代码的编辑器的一致性。

On the discussion between Jim and Thomas Wouters in the comments.

The issue was… since the width of tabs and spaces both can vary — and since programmers can’t agree on either width — why is it that tabs bear the blame.

I agree with Jim on that — tabs are NOT evil in and of themselves. But there is a problem…

With spaces I can control how “MY OWN CODE” looks in EVERY editor in the world. If I use 4 spaces — then no matter what editor you open my code in, it will have the same distance from the left margin. With tabs I am at the mercy of the tab-width setting for the editor — even for MY OWN CODE. And I don’t like that.

So while it is true that even spaces can’t guarantee consistency — they at least afford you more control over the look of your OWN code everywhere — something that tabs can’t.

I think it’s NOT the consistency in the programmers writing the code — but the consistency in editors showing that code — that spaces make easier to achieve (and impose).