Question

为什么PEP 8 recommend not having spaces around = in a keyword argument or a default parameter value？

这是否与在Python代码中每隔一次出现=时推荐空格不一致？

如何：

func(1, 2, very_long_variable_name=another_very_long_variable_name)

优于：

func(1, 2, very_long_variable_name = another_very_long_variable_name)

我们将非常感谢Python BDFL对讨论/解释的任何链接。

请注意，这个问题更多的是关于kwargs而不是默认值，我只是使用了PEP 8中的措辞。

我不是在征求意见。我在问这个决定背后的原因。这更像是问为什么我会在C程序中使用{与if语句相同的行，而不是我应该使用它还是不

Answer 1

我想这是因为关键字参数与变量赋值本质上是不同的。

例如，有很多这样的代码：

kw1 = some_value
kw2 = some_value
kw3 = some_value
some_func(
    1,
    2,
    kw1=kw1,
    kw2=kw2,
    kw3=kw3)

如您所见，将变量分配给名称完全相同的关键字参数是完全合理的，因此它提高了可见性，无需空格即可查看它们。我们更容易认识到我们正在使用关键字参数而不是为自己分配变量。

此外，参数往往在同一行，而赋值通常都是各自的一行，因此节省空间可能是一个重要的问题。

Answer 2

我不会将very_long_variable_name用作默认参数。所以考虑一下：

func(1, 2, axis='x', angle=90, size=450, name='foo bar')

对此：

func(1, 2, axis = 'x', angle = 90, size = 450, name = 'foo bar')

此外，将变量用作默认值没有多大意义。也许是一些常量变量（它们不是真正的常量），在这种情况下，我会使用全部大写的名称，描述性尽可能短。所以没有其他__ __。

Answer 3

有利有弊。

我非常不喜欢符合PEP8标准的代码。我并不认为very_long_variable_name=another_very_long_variable_name可能比人类更容易阅读 very_long_variable_name = another_very_long_variable_name。这不是人们阅读的方式。这是一种额外的认知负荷，特别是在没有语法高亮的情况下。

然而，有一个显着的好处。如果遵守间距规则，则可以更有效地使用工具 搜索参数。

Answer 4

IMO省去了args的空间，为arg / value对提供了更清晰的视觉分组;它看起来不那么杂乱。

Answer 5

我认为这有几个原因，尽管我可能只是合理化了：

它节省了空间，允许更多的函数定义和调用适合一行，并为参数名称本身节省更多空间。
通过连接每个关键字和值，您可以更容易地用逗号后面的空格分隔不同的参数。这意味着您可以快速了解您提供的论点数量。
语法与变量赋值不同，后者可能具有相同的名称。
此外，语法（甚至更多）不同于等式检查a == b，它也可以是调用中的有效表达式。

Answer 6

对我来说，它使代码更具可读性，因此是一个很好的约定。

我认为变量分配和函数关键字分配在样式方面的主要区别在于，前者在一行上应该只有一个=，而通常有多个=在后者的一行上。

如果没有其他考虑，我们宁愿foo = 42胜过foo=42，因为后者不是等号通常的格式，而且前者在视觉上很好地用空格分隔了变量和值

但是，当一行上有多个分配时，我们更喜欢f(foo=42, bar=43, baz=44)而不是f(foo = 42, bar = 43, baz = 44)，因为前者在视觉上用空格分隔了多个分配，而后者则没有，因此很难查看关键字/值对的位置。

这是另一种表达方式：约定后有一致性。一致性是这样的：通过空格使“最高分离级别”在视觉上更加清晰。较低级别的分隔不是（因为它将与分隔较高级别的空白混淆）。对于变量分配，最高的分隔级别是变量和值之间。对于功能关键字分配，最高级别的分隔是各个分配本身之间。

Answer 7

我个人认为，无论编程/标记语言如何，在所有赋值运算符 = 之前和之后的单个空格都应该是标准的，因为它有助于眼睛区分不同通道的标记 （即，将变量/参数名称标记与赋值运算符标记 = 与值标记/表达式值标记序列隔离）。

将三个不同通道的三个标记集中到一个“参数-名称-赋值-运算符-值/表达式-元组”标记中既不可读也不直观。

例如，让我们考虑非分隔标记：

def my_func(par1: str, par2: str):
    print('%s %s' % (par1, par2))

cond = 'conditional string'
my_func(par1='string with a lot of spaces', par2=cond if not cond == None else 'no string')

当然，传递给 par2 的值可能应该存储到变量中，而不是作为“三元”表达式传递...

par2 = cond if not cond == None else 'no string'
my_func(par1='string with a lot of spaces', par2=par2)

...但是我们是否应该决定使用三元表达式，我发现在赋值运算符前后添加分隔空格更易读，几乎就像一个字典对象（python 参数序列基本上是）：< /p>

my_func(par1 = 'string with a lot of spaces', 
        par2 = cond if not cond == None else 'no string')
# OR
par2 = cond if not cond == None else 'no string'
my_func(par1 = 'string with a lot of spaces', par2 = par2)

PEP 8，为什么关键字参数中的'='周围没有空格或默认参数值？

7 个答案: