Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Does PEP 8 require whitespace around operators in function arguments?

I have this code:

some_list = range(a, b+1) 

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

missing whitespace around operator 

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

some_list = range(a, b + 1) 

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

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

like image 684
wxl24life Avatar asked Aug 11 '13 11:08

wxl24life


People also ask

How many blank lines does the PEP8 Standard recommend to use between statements in a function definition in Python?

Two blank lines should be both before and after class definitions. One blank line should be both before and after method definitions. You should use blank lines conservatively within your code to separate groups of functions.

How many blank lines does the PEP8 Standard recommend to use between top level function definitions within a Python module?

PEP8 says you have to surround top level functions with 2 lines, however if you were to have a constant/global variable there, instead of those functions it could have easily been 1 line.

Which choice is PEP 8 compliant as the name of a class?

I try to adhere to the style guide for Python code (also known as PEP 8). Accordingly, the preferred way to name a class is using CamelCase: Almost without exception, class names use the CapWords convention.


2 Answers

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.

Originally, PEP 8 contained the phrase:

Use spaces around arithmetic operators

Under that rule,

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 plugin uses under the hood) implemented for several years.

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

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 ).

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

Thus the PEP, in its current form, does not dictate 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".

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 requires whitespace 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.

like image 112
Mark Amery Avatar answered Sep 28 '22 17:09

Mark Amery


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).

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

Edit:

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

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

            end = _w(s, end + 1).end() 
like image 42
mustafa.0x Avatar answered Sep 28 '22 17:09

mustafa.0x