什么時候可以在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!