Adapted fix to work identical to format #10999
Conversation
|
| code | total | + violation | - violation | + fix | - fix |
|---|---|---|---|---|---|
| E203 | 3 | 0 | 3 | 0 | 0 |
MichaReiser
added
bug
|
Are these ecosystem checks showing new false negatives? |
| #: E203 tab before : | ||
| predictions = predictions[ | ||
| len(past_covariates) // datamodule.hparams["downsample"] : | ||
| ] |
There was a problem hiding this comment.
Can we add two more examples where the line end:
- in a comment
- in a line continuation
There was a problem hiding this comment.
Right, those would both be legal continuations. Didn't think about that, but will try to add those in the coming days
There was a problem hiding this comment.
I added the comment case, but can't figure out how to do the line continuation, without basically rewriting the rule since the \ doesn't show up in the token stream. I could try to adapt E502 for it, if you consider the case important.
On the bright side, both ruff format and black remove a \ in the example situation anyway so there would be no continuing conflict.
There was a problem hiding this comment.
You could try to use SimpleTokenizer when you found a potential violation to lex the text coming right after the token and see if the next token is a line continuation.
crates/ruff_linter/src/rules/pycodestyle/rules/logical_lines/extraneous_whitespace.rs
Show resolved
Hide resolved
I would say yes. They all have the same structure as the minimal reproducible example in the ticket. |
Summary
The fix for E203 now produces the same result as ruff format in cases where a slice ends on a colon and the closing square bracket is on the following line.
Refers to #10973
Test Plan
The minimal reproduction case in the ticket was added as test case producing no error. Additional cases with multiple spaces or a tab before the colon where added to make sure that the rule still finds these.