为什么PEP 8建议不要=在关键字参数或默认参数值中使用空格？
这是否与=在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语句使用同一行，而不是是否应该使用它。
Answers:
我猜这是因为关键字参数与变量赋值本质上是不同的。
例如，有很多这样的代码：
kw1 = some_value
kw2 = some_value
kw3 = some_value
some_func(
1,
2,
kw1=kw1,
kw2=kw2,
kw3=kw3)如您所见，将变量分配给名称完全相同的关键字参数是完全有意义的，因此可以提高可读性，使它们看不到空格。更容易认识到我们正在使用关键字参数，而不是为其本身分配变量。
同样，参数往往在同一行中，而赋值通常每个都在各自的行中，因此节省空间可能是一个重要问题。
kw1 = kw1, kw2 = kw2;）更具可读性，但也许那正是Guido和Barry的想法。
我不会使用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')同样，将变量用作默认值也没有多大意义。也许某些常量变量（实际上不是常量），在这种情况下，我将使用全为大写的名称，以描述性的方式表示，但尽可能简短。所以没有another_very _...
有优点也有缺点。
我非常不喜欢PPE8兼容代码的读取方式。我不very_long_variable_name=another_very_long_variable_name接受比人类更具可读性
的论点very_long_variable_name = another_very_long_variable_name。人们不是这样阅读的。这是额外的认知负担，尤其是在没有语法突出显示的情况下。
但是，这有很大的好处。如果遵守间隔规则，则使使用工具专门搜索参数更加有效。
IMO省略了用于args的空间，从而提供了更清晰的arg / value对可视分组。看起来不那么混乱。
arg1=40方法更具可读性，因为这种关系更加明显。
对我来说，它使代码更具可读性，因此是一个很好的约定。
我认为变量分配和函数关键字分配在样式方面的主要区别在于=，前者在一行上应该只有一个，而通常有多个=。
如果没有其他考虑，我们宁愿foo = 42使用foo=42，因为后者不是等号通常的格式，并且因为前者在视觉上很好地用空格分隔了变量和值。
但是，当有一行中的多个任务，我们更f(foo=42, bar=43, baz=44)要f(foo = 42, bar = 43, baz = 44)，因为前者在视觉上与分离空白的几个任务，而后者则没有，使得它有点难以看到的关键字/值对。
这里是把它的另一种方式：还有就是约定背后的一致性。一致性是这样的：通过空格使“最高分离级别”在视觉上更加清晰。较低级别的分隔不是（因为它将与分隔较高级别的空白混淆）。对于变量分配，最高的分隔级别是变量和值之间。对于功能关键字分配，最高的分隔级别是各个分配本身之间的分隔。
{在if（定义相同的字符数之后）换行但不要在类定义中插入新行是个好主意。关键字参数也不同于默认值，但仍使用相同的样式建议。