什么时候可以在Python中使用空格来提高可读性？

Question

我来自其他使用大量空格以提高可读性的语言。 我通常会看到以下类似的python代码行：

my_data_1 = {'state': ['Alabama', 'Alaska'], 'abbv': ['AL', 'AK'], 'area': [52423, 656424], 'pop': [4040587, 550043]}

我发现很难快速扫描并识别数据结构，尤其是当它变得比这更复杂时。 我知道Python对于 空格 缩进不敏感，因此我尝试了以下两个其他选择：

my_data_2 = {'state': ['Alabama', 'Alaska'],
             'abbv': ['AL', 'AK'],
             'area': [52423, 656424],
             'pop': [4040587, 550043]}

my_data_3 = {'state': ['Alabama', 'Alaska'],
             'abbv' : ['AL',      'AK'],
             'area' : [52423,     656424],
             'pop'  : [4040587,   550043]}

我很惊讶它们像单行版本一样工作。

我知道缩进是如何代替代码块的C形{...} ，但是我找不到有关何时忽略空格的任何文档。

什么时候可以使用空格来提高可读性？

Answer 1

Python对空格不是特别敏感。 当缩进影响解析时，特别是缩进语句开始之前的缩进 ，缩进是敏感的。 除了用于分隔其他标记之外，其他空白通常被忽略。 这包括：

• dict或set文字的{...}内的空格。
• 空格内[...]一的list文字。
• 任何带括号的表达式内的空格。

• 在一行的开始处留有空格：

   this = whitespace \\ + does \\ + not \\ + count 

PEP-8建议采用以下格式：

my_data_2 = {
    'state': ['Alabama', 'Alaska'],
    'abbv': ['AL', 'AK'],
    'area': [52423, 656424],
    'pop': [4040587, 550043]
}

Answer 2

它的：

my_data_2 = {
    "state": ["Alabama", "Alaska"],
    "abbv": ["AL", "AK"],
    "area": [52423, 656424],
    "pop": [4040587, 550043],
}

我怎么知道？

布莱克告诉我。

Answer 3

从python的禅宗：

可读性很重要。

关于何时可以接受，我相信垂直对齐的代码有助于提高可读性，这通常是一个自以为是的话题。 有些人讨厌垂直对齐的代码。 如果它可以帮助您阅读它，那么它将起作用（除非必须对代码进行审查）。

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!