Pycodestyle: E226: 'missing whitespace' introspection issue

Created on 11 Dec 2013  路  10Comments  路  Source: PyCQA/pycodestyle

I'm getting "PEP 8: missing whitespace around arithmetic operator" introspection flag in cases where I should not, per this section of Pep 8:

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

Yes:

i = i + 1
submitted += 1
x = x_2 - 1
hypot2 = x_x + y*y
c = (a+b) * (a-b)"

This may be to a change in Pep 8 that this tool hasn't caught up with:

http://hg.python.org/peps/rev/37af28ad2972
http://hg.python.org/peps/rev/16dd63848921

opinion

All 10 comments

Which version of pep8 do you run ?

The check for whitespace around arithmetic operators is disabled in the default configuration (E226)

this is no opinion, but a faithful representation of the PEP, which was patched in 2012 to reflect guido鈥檚 original opinion.

the check should not be deactivated but instead only trigger if the spaces are missing around the lowest-priority binary operator in the expression, or there are spaces around the highest-priority operator.

i.e. yes:

(a+b) * (a-b)
(a+b)*a - b
(a+b) * a - b
x*x + y*y
a * 2
x + 1

no:

(a + b) * (a - b) # too spaceous
(a+b) * a-b       # misleading
x * x + y * y     # too spaceous
x * x+y * y       # misleading
a*2               # too cramped
x+1               # too cramped

in other words: expressions (with binary operators) should always have spaces around at least one (the least priority) binary operator, and expressions with at least two different binary operators should have no spaces around at least the highest-priority operator.

I'm using the Anaconda package in sublime Text, which gets it PEP8 linting guidelines form this repo.

A few days ago I started noticing a lot of lines highlighted as E226 violations. Checking right noe, I see that for example the line:

(a+b) * a - b

is marked as a violation, when it clearly shouldn't. Did something change on this end regarding E226?

Here is the issue I opened on that package, BTW.

@flying-sheep : Even with that change, it flags things as in violation that aren't by applying the rule to every operator without whitespace.

743 points out that this is also especially odd for complex numbers (1+2j) where the repr omits spaces

Relatedly, it would be helpful to be able to disable the error for division operators with literal integer operands on both sides, which (in py3+) literally represent fractions. y = 1/128 - x seems clearer than y = 1 / 128 - x

seems clearer than

this isn't what pep8 says -- you can disable this locally if you'd like by ignoring E226

That鈥檚 pretty much exactly what PEP 8 says:

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:

# Correct:
...
hypot2 = x*x + y*y
c = (a+b) * (a-b)
# Wrong:
...
hypot2 = x * x + y * y
c = (a + b) * (a - b)

E226 is disabled by default because pycodestyle would erroneously report E226 for perfectly compliant lines like y = 1/128 - x.

This makes pycodestyle less useful since it doesn鈥檛 complain about broken whitespace like y =1.

from pycodestyle's perspective it's impossible to differentiate the two cases -- the only reason it works for * and / is by accident -- as a side-effect of enabling those operators to mean keyword only / named only arguments

So an implementation detail: pycodestyle is ignorant of operator precedence.

No reason it can鈥檛 be fixed.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

daspecster picture daspecster  路  9Comments

Behoston picture Behoston  路  6Comments

Nyrio picture Nyrio  路  4Comments

willhardy picture willhardy  路  5Comments

garawalid picture garawalid  路  4Comments