-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[pycodestyle
] Respect isort
settings in blank line rules (E3*
)
#10096
Conversation
0d05d48
to
c43a07e
Compare
stylist, | ||
diagnostics, | ||
); | ||
state.class_status.update(&logical_line); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The state update logic used to be inside of check_line
. Moving the state handling out has the benefit that we can skip calling check_line
and it also separates the state update logic from the actual checking logic which I find easier to understand.
|
code | total | + violation | - violation | + fix | - fix |
---|---|---|---|---|---|
E301 | 14 | 14 | 0 | 0 | 0 |
PLR0917 | 12 | 6 | 6 | 0 | 0 |
E302 | 3 | 3 | 0 | 0 | 0 |
Formatter (stable)
✅ ecosystem check detected no format changes.
Formatter (preview)
✅ ecosystem check detected no format changes.
Hmm, it's slightly more complicated than that...
It doesn't handle the above correctly (should raise an error) because it assumes that it is after an import. |
I don't know that I have better suggestions, but I'll admit that I'm nervous to make the rule contingent on whether another rule is enabled, since it means |
Hmm that's a good point. The alternative is to never touch blank lines after imports and direct users towards isort? Although that's a bit overkill if all you want is 2 blank lines |
So the options I see are
|
I was thinking about that one. As you said it's a bit weird to use options from another rule, but that allows using both rule sets.
This option is seems more straightforward to implement, document and maintain. |
8feb4fa
to
94d04a6
Compare
pycodestyle
] Respect isort
settings in blank line rules (E3*
)
2fcdfbb
to
066cc98
Compare
The ecosystem changes look okay to me. It's not the main change but i must have fixed those rules by setting |
@hoel-bagard would you mind taking a look at the changes? I think you know the rule the best. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look good to me, I just had two questions about parts that weren't clear to me.
Also, not important but some ifs were over indented so I made a PR to fix that.
Some ifs are over-indented in #10096 as a result of refactoring, this PR simply fixes that.
Just to confirm, this change won't fix the issue in #10077, correct? I'm testing things out with this branch but still see the infinite loop when running on .pyi files. |
Nice find. It seems specific to a class coming after imports when using |
Some ifs are over-indented in #10096 as a result of refactoring, this PR simply fixes that.
@hoel-bagard thank you for your review and fixing the indentation. |
425e2d1
to
7bd7e71
Compare
…stral-sh#10096) ## Summary This PR changes the `E3*` rules to respect the `isort` `lines-after-imports` and `lines-between-types` settings. Specifically, the following rules required changing * `TooManyBlannkLines` : Respects both settings. * `BlankLinesTopLevel`: Respects `lines-after-imports`. Doesn't need to respect `lines-between-types` because it only applies to classes and functions The downside of this approach is that `isort` and the blank line rules emit a diagnostic when there are too many blank lines. The fixes aren't identical, the blank line is less opinionated, but blank lines accepts the fix of `isort`. <details> <summary>Outdated approach</summary> Fixes astral-sh#10077 (comment) This PR changes the blank line rules to not enforce the number of blank lines after imports (top-level) if isort is enabled and leave it to isort to enforce the right number of lines (depends on the `isort.lines-after-imports` and `isort.lines-between-types` settings). The reason to give `isort` precedence over the blank line rules is that they are configurable. Users that always want to blank lines after imports can use `isort.lines-after-imports=2` to enforce that (specifically for imports). This PR does not fix the incompatibility with the formatter in pyi files that only uses 0 to 1 blank lines. I'll address this separately. </details> ## Review The first commit is a small refactor that simplified implementing the fix (and makes it easier to reason about what's mutable and what's not). ## Test Plan I added a new test and verified that it fails with an error that the fix never converges. I verified the snapshot output after implementing the fix. --------- Co-authored-by: Hoël Bagard <[email protected]>
Summary
This PR changes the
E3*
rules to respect theisort
lines-after-imports
andlines-between-types
settings. Specifically, the following rules required changingTooManyBlannkLines
: Respects both settings.BlankLinesTopLevel
: Respectslines-after-imports
. Doesn't need to respectlines-between-types
because it only applies to classes and functionsThe downside of this approach is that
isort
and the blank line rules emit a diagnostic when there are too many blank lines. The fixes aren't identical, the blank line is less opinionated, but blank lines accepts the fix ofisort
.Outdated approach
Fixes https://github.com//issues/10077#issuecomment-1961266981This PR changes the blank line rules to not enforce the number of blank lines after imports (top-level) if isort is enabled and leave it to isort to enforce the right number of lines (depends on the
isort.lines-after-imports
andisort.lines-between-types
settings).The reason to give
isort
precedence over the blank line rules is that they are configurable. Users that always want to blank lines after imports can useisort.lines-after-imports=2
to enforce that (specifically for imports).This PR does not fix the incompatibility with the formatter in pyi files that only uses 0 to 1 blank lines. I'll address this separately.
Review
The first commit is a small refactor that simplified implementing the fix (and makes it easier to reason about what's mutable and what's not).
Test Plan
I added a new test and verified that it fails with an error that the fix never converges. I verified the snapshot output after implementing the fix.