Python PEP 8 是否要求函数参数中的运算符周围有空格?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/18171560/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-19 10:02:07  来源:igfitidea点击:

Does PEP 8 require whitespace around operators in function arguments?

pythoncoding-stylepep8

提问by wxl24life

I have this code:

我有这个代码:

some_list = range(a, b+1)

After checking my coding style with pep8 plugin for vim, I got this warning:

在使用pep8 插件为 vim检查我的编码风格后,我收到了这个警告:

missing whitespace around operator

It seems that to be compliant with PEP 8 I should instead write this?

似乎要符合 PEP 8 我应该写这个?

some_list = range(a, b + 1)

But I have read PEP 8 - Style Guide for Python Codeseveral times and just can't find the rule applied to the warning above.

但是我已经多次阅读PEP 8 - Python 代码风格指南,只是找不到适用于上述警告的规则。

So I want to know: when using PEP-8 style, is whitespace needed around operators(+,-,*,/,etc) in a function's arguments?

所以我想知道:在使用 PEP-8 样式时,函数参数中的运算符(+、-、*、/等)周围是否需要空格?

采纳答案by mustafa.0x

http://www.python.org/dev/peps/pep-0008/#other-recommendations

http://www.python.org/dev/peps/pep-0008/#other-recommendations

Always surround these binary operators with a single space on either side: assignment (=), augmented assignment (+=, -= etc.), comparisons (==, <, >, !=, <>, <=, >=, in, not in, is, is not), Booleans (and, or, not).

始终用一个空格将这些二元运算符括起来:赋值 (=)、增强赋值(+=、-= 等)、比较(==、<、>、!=、<>、<=、>= , in, not in, is, is not), Booleans (and, or, not)。

The exception to that is when =is used to set named parameters.

例外情况是 when=用于设置命名参数。

Edit:

编辑:

I've looked through the source code of Python's standard library and found an occurrence of the scenario presented above:

我查看了 Python 标准库的源代码,发现了上述场景的发生:

http://hg.python.org/cpython/file/9ddc63c039ba/Lib/json/decoder.py#l203

http://hg.python.org/cpython/file/9ddc63c039ba/Lib/json/decoder.py#l203

            end = _w(s, end + 1).end()

回答by Mark Amery

Your Vim plugin was wrong when you asked in 2013... but right in 2010, when it was authored. PEP 8 has changed on several occasions, and the answer to your question has changed as well.

当您在 2013 年问起时,您的 Vim 插件是错误的……但在 2010 年创作时是正确的。PEP 8 已多次更改,您的问题的答案也已更改。

Originally, PEP 8 contained the phrase:

最初,PEP 8 包含以下短语:

Use spaces around arithmetic operators

在算术运算符周围使用空格

Under thatrule,

那个规则下,

range(a, b+1)

is unambiguously wrong and should be written as

显然是错误的,应该写成

range(a, b + 1)

That is the rule that pycodestyle(the Python linter, previously known as pep8.py, that the asker's Vim pluginuses under the hood) implemented for several years.

这是pycodestyle(Python linter,以前称为 pep8.py,提问者的Vim 插件在幕后使用的)实施了几年的规则。

However, this was changedin April 2012. The straightforward language that left no room for discretion was replaced with this much woollier advice:

然而,在 2012 年 4 月发生了变化。 没有留下任何自由裁量余地的直截了当的语言被以下更粗暴的建议所取代:

If operators with different priorities are used, consider adding whitespace around the operators with the lowest priority(ies). Use your own judgment; however, never use more than one space, and always have the same amount of whitespace on both sides of a binary operator.

如果使用具有不同优先级的运算符,请考虑在具有最低优先级的运算符周围添加空格。使用你自己的判断;但是,永远不要使用超过一个空格,并且在二元运算符的两边总是有相同数量的空格。

Confusingly, the examples that illustrate this rule were originally left unchanged (and hence in contradiction to the prose). This was eventually fixed, but not very well, and the examples remain confusing, seeming to imply a much stricter and less subjective rule than the prose does.

令人困惑的是,说明这条规则的例子最初没有改变(因此与散文相矛盾)。这最终得到了解决,但不是很好,并且示例仍然令人困惑,似乎暗示了比散文更严格和更少主观的规则。

There is still a rule requiring whitespace around some particular operators:

仍然有一条规则要求某些特定运算符周围空格:

Always surround these binary operators with a single space on either side: assignment ( =), augmented assignment ( +=, -=etc.), comparisons ( ==, <, >, !=, <>, <=, >=, in, not in, is, is not), Booleans ( and, or, not).

总是围绕这些二元运算符在任一侧的单个空间:分配(=),增量赋值(+=-=等),比较(==<>!=<><=>=innot inisis not),布尔值(andornot)。

but note that this rule is explicit about which operators it refers to and arithmetic operators like +are notin the list.

但请注意,此规则明确说明了它所指的运算符和算术运算符之类+不在列表中。

Thus the PEP, in its current form, does notdictate whether or not you should use spaces around the +operator (or other arithmetic operators like *and /and **). You are free to "use your own judgement".

因此,当前形式的 PEP并没有规定您是否应该在+运算符(或其他算术运算符,如*and/**)周围使用空格。你可以自由地“使用你自己的判断”

By the way, the pycodestyle linter changed its behaviour in late 2012 to reflect the change in the PEP, separating the rules about using whitespace around operators into two error codes, E225 (for failure to use whitespace around the operators that PEP 8 still requireswhitespace around), which is on by default, and E226 (for failure to use whitespace around arithmetic operators), which is ignored by default. The question asker here must've been using a slightly outdated version of the linter when he asked this question in 2013, given the error that he saw.

顺便说一下,pycodestyle linter在 2012 年末改变了它的行为以反映 PEP 的变化,将有关在运算符周围使用空格的规则分成两个错误代码 E225(对于 PEP 8 仍然需要空格的运算符周围没有使用空格的失败周围),默认情况下是打开的,以及 E226(在算术运算符周围使用空格失败),默认情况下被忽略。鉴于他看到的错误,这里的提问者在 2013 年提出这个问题时一定使用了稍微过时的 linter 版本。

回答by Eduardo Alberto Duarte Lacerda

For arithmetic operators I usually put spaces around + and - but not in *, ** and /. Here's an example:

对于算术运算符,我通常在 + 和 - 周围放置空格,但不在 *、** 和 / 中。下面是一个例子:

(...)
alpha__w = (wave__w - central_w_par*doppler_factor)/sig_par
e1__w = np.exp(-.5*(alpha__w**2))
Y1__w = norm*e1__w/(sig_par*(2*np.pi)**.5)
(...)