[pycodestyle] Add blank line(s) rules (E301, E302, E303, E304, E305, E306)
#9266
Conversation
decorator -> comment -> decorator was causing a false positive.
Fix false positive where a method following an if (or other indentation inducing keyword) would trigger E301.
This also move the trigger on an async def from the def to the async.
Make the comment stick to the following line instead of the preceding one.
| /// Checks for missing blank lines between methods of a class. | ||
| /// | ||
| /// ## Why is this bad? | ||
| /// PEP 8 recommends the use of blank lines as follows: | ||
| /// - Two blank lines are expected between functions and classes | ||
| /// - One blank line is expected between methods of a class. |
There was a problem hiding this comment.
Why do we mention the recommended spacing between functions and classes if this rule is just for methods of a class? It might make sense to just say "PEP 8 recommends exactly one blank line between methods of a class". We should also not specify "missing" if this will also trigger for "too many" blank lines, instead we should say "Checks for the correct number of blank lines between methods of a class.
We could move all of this into "What it does" and have "Why is this bad" focus on consistency with PEP 8? I don't have strong feelings about that though.
There was a problem hiding this comment.
Why do we mention the recommended spacing between functions and classes if this rule is just for methods of a class? It might make sense to just say "PEP 8 recommends exactly one blank line between methods of a class".
Done in 3d5cc84
We should also not specify "missing" if this will also trigger for "too many" blank lines, instead we should say "Checks for the correct number of blank lines between methods of a class.
This rule does not trigger for too many blank lines.
There was a problem hiding this comment.
We could move all of this into "What it does" and have "Why is this bad" focus on consistency with PEP 8? I don't have strong feelings about that though.
I don't have strong feelings about this either, I can try to change it if you want.
hoel-bagard
force-pushed
the
blank_lines_non_logical
branch
from
ba8ee05
to
a28f916
Compare
|
Merged?! Yay! Thanks for the hard work @hoel-bagard! |
|
Thanks for addressing my feedback! |
|
I upgraded to ruff 0.2.2, where this is included. But it's still hidden behind some compiler flag? I can't test it without compiling ruff on my own? |
|
Great work @hoel-bagard ! I come from this SO comment I followed all the previous PRs related to this without much hope. Amazing that I would have been blocked if I checked this only 2 weeks ago. |
…4`, `E305`, `E306`) (astral-sh#9266) Co-authored-by: Micha Reiser <micha@reiser.io>
Summary
This PR is part of #2402, it adds the
E301,E302,E303,E304,E305,E306error rules along with their fixes.This PR is based on #8720, but does not use logical lines and instead works directly on tokens.
Test Plan
The test fixture uses the one from pycodestyle with a some added tests.