PEP 8，为什么 '=' 周围没有空格在关键字参数或默认参数值中？
为什么 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 语句在同一行上使用{，而不是是否 > 我该用还是不用。
Why does PEP 8 recommend not having spaces around = in a keyword argument or a default parameter value?
Is this inconsistent with recommending spaces around every other occurrence of = in Python code?
How is:
func(1, 2, very_long_variable_name=another_very_long_variable_name)
better than:
func(1, 2, very_long_variable_name = another_very_long_variable_name)
Any links to discussion/explanation by Python's BDFL will be appreciated.
Mind, this question is more about kwargs than default values, i just used the phrasing from PEP 8.
I'm not soliciting opinions. I'm asking for reasons behind this decision. It's more like asking why would I use { on the same line as if statement in a C program, not whether I should use it or not.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我猜这是因为关键字参数与变量赋值本质上不同。
例如，有很多这样的代码：
如您所见，将变量分配给名称完全相同的关键字参数是完全有意义的，因此可以提高在没有空格的情况下查看它们的可读性。更容易认识到我们正在使用关键字参数，而不是将变量分配给自身。
此外，参数往往位于同一行，而赋值通常位于各自的行中，因此节省空间可能是一个重要问题。
I guess that it is because a keyword argument is essentially different than a variable assignment.
For example, there is plenty of code like this:
As you see, it makes complete sense to assign a variable to a keyword argument named exactly the same, so it improves readability to see them without spaces. It is easier to recognize that we are using keyword arguments and not assigning a variable to itself.
Also, parameters tend to go in the same line whereas assignments usually are each one in their own line, so saving space is likely to be an important matter there.
有优点也有缺点。
我非常不喜欢 PEP8 兼容代码的读取方式。我不相信
very_long_variable_name=another_very_long_variable_name比very_long_variable_name = another_very_long_variable_name。人们不是这样读书的。这是额外的认知负担，特别是在没有语法突出显示的情况下。
然而，这样做有一个显着的好处。如果遵守间距规则，则使用工具专门搜索参数会更加有效。
There are pros and cons.
I very much dislike how PEP8 compliant code reads. I don't buy into the argument that
very_long_variable_name=another_very_long_variable_namecan ever be more human readable thanvery_long_variable_name = another_very_long_variable_name.This is not how people read. It's an additional cognitive load, particularly in the absence of syntax highlighting.
There is a significant benefit, however. If the spacing rules are adhered to, it makes searching for parameters exclusively using tools much more effective.
我不会使用very_long_variable_name 作为默认参数。因此，考虑一下
：此外
，使用变量作为默认值没有多大意义。也许是一些常量变量（实际上并不是常量），在这种情况下，我会使用全部大写的名称，具有描述性但尽可能短。所以没有另一个_非常_...
I wouldn't use very_long_variable_name as a default argument. So consider this:
over this:
Also, it doesn't make much sense to use variables as default values. Perhaps some constant variables (which aren't really constants) and in that case I would use names that are all caps, descriptive yet short as possible. So no another_very_...
IMO 留出 args 的空格可以提供更清晰的 arg/值对的视觉分组；它看起来不那么混乱。
IMO leaving out the spaces for args provides cleaner visual grouping of the arg/value pairs; it looks less cluttered.
对我来说，它使代码更具可读性，因此是一个很好的约定。
我认为变量赋值和函数关键字赋值在风格方面的主要区别在于，前者的一行上只能有一个
=，而通常有多个=code>s 在后者的一行上。如果没有其他考虑，我们会更喜欢
foo = 42而不是foo=42，因为后者不是等号通常的格式，而且因为前者视觉效果很好用空格分隔变量和值。但是，当一行上有多个赋值时，我们更喜欢使用
f(foo=42, bar=43, baz=44)而不是f(foo = 42, bar = 43, baz = 44 )，因为前者在视觉上用空格分隔了多个赋值，而后者则没有，这使得查看关键字/值对的位置变得有点困难。这是另一种表达方式：约定背后有一致性。这种一致性是这样的：“最高层次的分离”通过空间在视觉上变得更加清晰。任何较低级别的分隔都不是（因为它会与分隔较高级别的空格混淆）。对于变量赋值，最高级别的分离是变量和值之间。对于函数关键字赋值，最高级别的分离是在各个赋值本身之间。
For me it makes code more readable and is thus a good convention.
I think the key difference in terms of style between variable assignments and function keyword assignments is that there should only be a single
=on a line for the former, whereas generally there are multiple=s on a line for the latter.If there were no other considerations, we would prefer
foo = 42tofoo=42, because the latter is not how equals signs are typically formatted, and because the former nicely visually separates the variable and value with whitespace.But when there are multiple assignments on one line, we prefer
f(foo=42, bar=43, baz=44)tof(foo = 42, bar = 43, baz = 44), because the former visually separates the several assignments with whitespace, whereas the latter does not, making it a bit harder to see where the keyword/value pairs are.Here's another way of putting it: there is a consistency behind the convention. That consistency is this: the "highest level of separation" is made visually clearer via spaces. Any lower levels of separation are not (because it would be confused with the whitespace separating the higher level). For variable assignment, the highest level of separation is between variable and value. For function keyword assignment, the highest level of separation is between the individual assignments themselves.
我个人认为，无论编程/标记语言如何，所有赋值运算符
=之前和之后的单个空格都应该是标准的，因为它有助于眼睛区分不同通道的标记 （即，将变量/参数名称标记与赋值运算符标记=与值标记/表达式值标记序列隔离）。将三个不同通道的三个标记聚集成单个“参数-名称-赋值-运算符-值/表达式-元组”标记既不可读也不直观。
例如，让我们考虑非分隔标记：
当然，传递给
par2的值可能应该存储到变量中，而不是作为“三元”表达式传递......但是我们应该决定吗？无论如何，要使用三元表达式，我发现在赋值运算符之前和之后添加分隔空格会更具可读性，几乎就像一个字典对象（Python 参数序列基本上是）：
I personally feel that a single space before and after ALL assignment operators
=should be standard regardless of the programming/markup language, because it helps the eye differentiate between tokens of different channels (i.e. isolating a variable/parameter name token, from an assignment operator token=, from a value token/sequence of expression value tokens).It is neither readable nor intuitive to clump three tokens of three different channels into a single "parameter-name-assignment-operator-value/expression-tuple" token.
For example, let's consider non-delimited tokens:
Granted, the value passed to
par2should probably be stored into a variable rather than passed as a "ternary" expression......but should we decide to use the ternary expression anyways, I find that adding the delimiting spaces before and after the assignment operators to be more readable, almost like a dictionary object (which python parameter sequences basically are):
我认为这有几个原因，尽管我可能只是在合理化：
a == b不同，后者也可以是调用内的有效表达式。I think there are several reasons for this, although I might just be rationalizing:
a == bwhich can also be valid expressions inside a call.