You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The pycodestyle rule lambda-assignment (E731) is supposed to check whether a lambda expression is being assigned to a variable and instead suggest using a def statement. However, Ruff's implementation appears to be incorrectly flagging a dataclass field with a default value consisting of a lambda expression as violation of this rule, whereas pycodestyle does not. Here is a short example:
Here is the command-line output of both Ruff and pycodestyle:
$ ruff check --isolated --select=E731 mycode.py
mycode.py:7:5: E731 Do not assign a `lambda` expression, use a `def`
Found 1 error.
$ pycodestyle --select=E731 mycode.py
(No output for pycodestyle, but exits successfully with status code 0.)
The examples above were run with ruff 0.3.4 and pycodestyle 2.11.1, which are the latest versions at the time of this writing.
This should apply to more classes than just dataclasses, but I'm not exactly sure where I would draw the line. You probably do want to flag cases where someone assigned a lambda to a class variable when it should have been a class or instance method, but I'm not sure which heuristics you want to apply.
I haven't tried reading the pycodestyle source code to see how they implemented it, but playing with my example above, I think their heuristic may just be whether or not an annotation is present on the class member declaration, which seems reasonable to me. Here are a few specific example with inline comments on whether pycodestyle reports a violation:
fromdataclassesimportdataclassfromtypingimportCallable# pycodestyle is happy with this@dataclassclassFilterDataclass:
filter: Callable[[str], bool] =lambda_: True# pycodestyle is happy with thisclassFilterClassWithCallableAnno:
filter: Callable[[str], bool] =lambda_: True# pycodestyle is happy with thisclassFilterClassWithAribtraryAnno:
filter: Foo=lambda_: True# pycodestyle is _not_ happy with this# mycode.py:24:5: E731 do not assign a lambda expression, use a defclassFilterClassWithoutAnno:
filter=lambda_: True
The text was updated successfully, but these errors were encountered:
## Summary
An annotated lambda assignment within a class scope is often
intentional. For example, within a dataclass or Pydantic model, these
are treated as fields rather than methods (and so can be passed values
in constructors).
I originally wrote this to special-case dataclasses and Pydantic
models... But was left feeling like we'd see more false positives here
for little gain (an annotated lambda within a `class` is likely
intentional?). Open to opinions, though.
Closes#10718.
The pycodestyle rule lambda-assignment (E731) is supposed to check whether a lambda expression is being assigned to a variable and instead suggest using a
def
statement. However, Ruff's implementation appears to be incorrectly flagging a dataclass field with a default value consisting of a lambda expression as violation of this rule, whereas pycodestyle does not. Here is a short example:Here is the command-line output of both Ruff and pycodestyle:
(No output for pycodestyle, but exits successfully with status code 0.)
The examples above were run with ruff 0.3.4 and pycodestyle 2.11.1, which are the latest versions at the time of this writing.
This should apply to more classes than just dataclasses, but I'm not exactly sure where I would draw the line. You probably do want to flag cases where someone assigned a lambda to a class variable when it should have been a class or instance method, but I'm not sure which heuristics you want to apply.
I haven't tried reading the pycodestyle source code to see how they implemented it, but playing with my example above, I think their heuristic may just be whether or not an annotation is present on the class member declaration, which seems reasonable to me. Here are a few specific example with inline comments on whether pycodestyle reports a violation:
The text was updated successfully, but these errors were encountered: