-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Harmonize E301 check with format in --preview mode? #10211
Comments
I don't know how complicated it is to support this, but I think changing |
I don't think that would be an easy change, but I'll have a look. One thing to note is that it would deviate from pycodestyle. ❯ pycodestyle foo.py
foo.py:11:5: E301 expected 1 blank line, found 0 |
@MichaReiser One way the to accept this syntax would be to keep track of the function name (since we would only allow the syntax if the name of the function is the same as the previous one) by modifying the enums as shown below. Then it should only be a matter of modifying the enum LogicalLineKind {
...
Function,
...
}
enum Follows {
...
Def,
...
} to enum LogicalLineKind {
...
Function(String),
...
}
enum Follows {
...
Def(String),
...
} I haven't done it yet, but I can give it a try if you think that's a good idea. |
We could also allow any function to follow a one-liner function. Right now we allow the first of the two snippets below, but not the second one. This is the same behavior as pycodestyle. def foo(self, x: int) -> int: ...
def bar(self, x: str) -> str: ...
def baz(self, x: int | str) -> int | str: return x def foo(self, x: int) -> int: ...
def bar(self, x: str) -> str: ...
def baz(self, x: int | str) -> int | str:
return x |
I think ideally the solution here wouldn't be sensitive to how many lines were in the function definition. E.g. This should still be accepted code style: @t.overload
def foo(x: int) -> int: ...
@t.overload
def foo(x: str) -> str: ...
def foo(x: int | str) -> int | str:
if not isinstance(x, (int, str)):
raise TypeError
return x |
I'm sorry. I should have linked to the formatter issue so you don't have to infer the formatter's rules (which can be difficult to debug). The style change is called dummy implementations and it makes the blank lines between two functions optional if the preceding function has a dummy ( Which is what you're proposing here:
I think it's a good compromise between pycodestyle and formatter compatibility (and it seems a sensible defaults for stubs to me). The lint rule is allowed to be slightly stricter than the formatter (the formatter makes the blank line optional, it doesn't remove it). That means we could enforce that the functions have the same name, but I don't think that's necessary. @jab what's your take on whether the functions should have the same name? Would we need to make the same change for methods? |
When formatting with |
@randolf-scholz Thank you for the suggestion! @AlexWaygood is working towards rule categorization (#1774) where it would make sense to have this kind of group. |
ruff format
allows overloaded method stubs to occur before the runtime definition with no blank line in between, which is good. But this style fails the E301 check (in preview mode only). Should these be harmonized?minimal code snippet that reproduces the bug
commands invoked
ruff version
The text was updated successfully, but these errors were encountered: