Implement remaining pycodestyle rules

[charliermarsh]

Note: some of the checked-off rules are still gated behind the logical_lines feature flag. To see the list of rules enabled in the current release, refer to the docs.

E1 Indentation

• E101 ("indentation contains mixed spaces and tabs")
• E111 ("indentation is not a multiple of four")
• E112 ("expected an indented block")
• E113 ("unexpected indentation")
• E114 ("indentation is not a multiple of four (comment)")
• E115 ("expected an indented block (comment)")
• E116 ("unexpected indentation (comment)")
• E117 ("over-indented")
• E122 ("continuation line missing indentation or outdented")
• E124 ("closing bracket does not match visual indentation")
• E125 ("continuation line with same indent as next logical line")
• E127 ("continuation line over-indented for visual indent")
• E128 ("continuation line under-indented for visual indent")
• E129 ("visually indented line with same indent as next logical line")
• E131 ("continuation line unaligned for hanging indent")

E2 Whitespace

• E201 ("whitespace after ‘(’")
• E202 ("whitespace before ‘)’")
• E203 ("whitespace before ‘,’, ‘;’, or ‘:’")
• E211 ("whitespace before ‘(’")
• E221 ("multiple spaces before operator")
• E222 ("multiple spaces after operator")
• E223 ("tab before operator")
• E224 ("tab after operator")
• E225 ("missing whitespace around operator")
• E227 ("missing whitespace around bitwise or shift operator")
• E228 ("missing whitespace around modulo operator")
• E231 ("missing whitespace after ‘,’, ‘;’, or ‘:’")
• E251 ("unexpected spaces around keyword / parameter equals")
• E261 ("at least two spaces before inline comment")
• E262 ("inline comment should start with ‘# ‘")
• E265 ("block comment should start with ‘# ‘")
• E266 ("too many leading ‘#’ for block comment")
• E271 ("multiple spaces after keyword")
• E272 ("multiple spaces before keyword")
• E273 ("tab after keyword")
• E274 ("tab before keyword")
• E275 ("missing whitespace after keyword")

E3 Blank line

• E301 ("expected 1 blank line, found 0")
• E302 ("expected 2 blank lines, found 0")
• E303 ("too many blank lines (3)")
• E304 ("blank lines found after function decorator")
• E305 ("expected 2 blank lines after end of function or class")
• E306 ("expected 1 blank line before a nested definition")

E4 Import

• E401 ("multiple imports on one line")
• E402 ("module level import not at top of file")

E5 Line length

• E501 ("line too long (82 > 79 characters)")
• E502 ("the backslash is redundant between brackets")

E7 Statement

• E701 ("multiple statements on one line (colon)")
• E702 ("multiple statements on one line (semicolon)")
• E703 ("statement ends with a semicolon")
• E704 ("multiple statements on one line (def)")
• E711 ("comparison to None should be ‘if cond is None:’")
• E712 ("comparison to True should be ‘if cond is True:’ or ‘if cond:’")
• E713 ("test for membership should be ‘not in’")
• E714 ("test for object identity should be ‘is not’")
• E721 ("do not compare types, use ‘isinstance()’")
• E722 ("do not use bare except, specify exception instead")
• E731 ("do not assign a lambda expression, use a def")
• E741 ("do not use variables named ‘l’, ‘O’, or ‘I’")
• E742 ("do not define classes named ‘l’, ‘O’, or ‘I’")
• E743 ("do not define functions named ‘l’, ‘O’, or ‘I’")

E9 Runtime

• E901 ("SyntaxError or IndentationError")
• E902 ("IOError")

W1 Indentation warning

• W191 ("indentation contains tabs")

W2 Whitespace warning

• W291 ("trailing whitespace")
• W292 ("no newline at end of file")
• W293 ("blank line contains whitespace")

W3 Blank line warning

• W391 ("blank line at end of file")

W5. Line break warning

• W505 ("doc line too long (82 > 79 characters)")

W6 Deprecation warning

• W605 ("invalid escape sequence ‘x’")

[charliermarsh]

I'm happy to support these, but I likely won't enable them by default -- I'd like them to be opt-in.

[charliermarsh]

(Also that tabulation is incomplete, but I'll finish it up later!)

[charliermarsh]

\cc @saadmk11

[charliermarsh]

I've updated this lint to include all the current pydocstyle rules, less those that are ignored in the default configuration and those that deal with pre-Python 3.7 code.

[charliermarsh]

First we need #1130.

[charliermarsh]

So far I have seven more rules done in #1130.

[pierrepo]

Thanks for this @charliermarsh
I'm using a lot pycodestyle and pydocstyle with my students to teach them PEP8 and PEP257. Using ruff will be a great plus.

[charliermarsh]

#1130 is up to 14 rules. Just trying to knock out a few each days.

[charliermarsh]

Knocked out eight more rules behind the feature flag.

[charliermarsh]

Four more done.

[charliermarsh]

One more in #3225.

[charliermarsh]

One more in #3249.

[charliermarsh]

One more in #3344.

[kapilt]

rust newb, if someone wants to try this feature set, how do we build ruff with logical-line feature flag support and these style rules enabled?

[update]
this seems to do it, following along on contributing.md

git clone https://github.com/charliermarsh/ruff.git
cd ruff
cargo build --all-features --release
cp target/release/ruff ~/bin

[spaceone]

rust newb, if someone wants to try this feature set, how do we build ruff with logical-line feature flag support and these style rules enabled?

@charliermarsh I would like to have a pip release for ruff with that special feature as pip/setup.py "package option" / "extra"/ "extras_require" enabled. So that you can call pip install ruff[logical-line] and have this enabled. Maybe it's possible to achieve that?

[charliermarsh]

I'm hoping that we can finish and release this soon enough that it's not worth shipping an extra_requires variant. (And if not, I'd probably rather ship with a command-line or feature flag rather than an extras, so that it's available regardless of how you install Ruff.)

[hoel-bagard]

@charliermarsh Since #9266 got merged, the E3 rules can be checked here.

[spaceone]

Are meanwhile all above checked rules now available, at least behind the preview flag?

[charliermarsh]

@spaceone - Yup, they're all behind --preview.

[buhtz]

How to handle problems with --preview error codes? Report them here or open an extra issue?

E303 (too-many-blank-lines) not working on this file for example:

# foo.py
class Foo:
    def __init__(self):
        pass


    def two(self):
        pass

Calling ruff 0.2.2 via ruff foo.py --preview.

[hoel-bagard]

@buhtz Have you selected the E303 rule ? For example with:

ruff foo.py --preview --select E3

[buhtz]

@buhtz Have you selected the E303 rule ? For example with:

ruff foo.py --preview --select E3

No, I have not. As discussed here and how I understand the docs the --preview flag to select all "preview" (unstable, new) rules.

EDIT: IMHO the docs are misleading.

$ ruff foo.py --preview --select E303
foo.py:7:5: E303 [*] Too many blank lines (2)
  |
7 |     def two(self):
  |     ^^^ E303
8 |         pass
  |
  = help: Remove extraneous blank line(s)

Found 1 error.
[*] 1 fixable with the `--fix` option.

[baco]

@buhtz Have you selected the E303 rule ? For example with:

ruff foo.py --preview --select E3

No, I have not. As discussed here and how I understand the docs the --preview flag to select all "preview" (unstable, new) rules.

Well... that's the issue. As for now, all the E3 rules have just arrived and are on their testing period, hence, the only way to try them is with the --preview flag.

You can see that here, in the Rules, and see that all the rules available under the --preview are marked with 🧪 (a test tube emoji). And the rules you are looking for:

all have the test tube emoji

[buhtz]

the only way to try them is with the --preview flag.

No, you are wrong. That flag alone does not help. You have to combine --preview with --select. That is the missing key fact here. I know you know it. But some readers might misunderstand that. Wording is very important here.

[baco]

Ahhh, ok, ok, that's right, the combination of both flags. --preview doesn't turn on all the “unstable rules”. The flag rather stops filtering out rules matching the “selection rules” (if that's a thing) that happen to be unstable.

Is that what you are pointing out here?

[buhtz]

Is that what you are pointing out here?

Exactly.

[kaddkaka]

Note: some of the checked-off rules are still gated behind the logical_lines feature flag. To see the list of rules enabled in the current release, refer to the docs.

Is this still true? Is there a better way than cross referencing https://docs.astral.sh/ruff/rules/#pycodestyle-e-w with the list in this issue?

Where can I find info about "logical_lines"? A search in the docs gave 0 matches.

[MichaReiser]

Note: some of the checked-off rules are still gated behind the logical_lines feature flag. To see the list of rules enabled in the current release, refer to the docs.

No, that's no longer the case. You can opt in by using --preview and enabling the desired rules (e.g. --extend-select=E3)

All checked rules in this issue are implemented as stable or preview rules and the rules use the same codes as pycodestyle. So there should be no need to cross-reference except if you need to know if the rule is preview only.

[shikari08]

Anyone know how to use the preview E3 Blank line rules in vscode with the ruff extension. I have the preview version installed in vscode.

[dhruvmanila]

@Daku24 By preview, we mean https://docs.astral.sh/ruff/preview/, you don't need to have the preview version of ruff-vscode extension. If you have a local config for Ruff, you can enable preview and include E3:

[tool.ruff.lint]
preview = true
extend-select = ["E3"]

If you don't have a Ruff config file or can't create or edit it, you can use lint.args.

I hope this helps :)

[Alex-ley-scrub]

This is awesome work 👏

Once E11, E12, and E13 rules are added with automatic fixes, if we run something like this:

ruff check foo.py --fix --preview --select E1

would we would get the ~same result as something like this?:

autopep8 foo.py --in-place [--aggressive] 

If so, that would be amazing! autopep8 is really good at fixing broken indentation and adding this to ruff would be 😍

E1 rules don't have automatic fixes at the minute - is that just a case of priority/time or is there a technical challenge / performance concern / reluctance for this to be default behaviour etc. as somewhat discussed in #1130