-
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
[red-knot] Check the return type of dunder methods #16249
Comments
I'm still not sure that this is actually something a type checker should check, rather than a type-aware linter. The type checker should check (where necessary/appropriate) that the return type is correct when these methods are (explicitly or implicitly) called. But if they're never called, there's no type safety issue. And we already have linter rules to guard against these antipatterns:
|
Yeah sorry. That's what I meant. We should check the return type when implicitly calling those operations and error if the dunder is incorrectly implemented. |
Okay, great! For ruff/crates/red_knot_python_semantic/src/types.rs Line 1519 in e84985e
In general, these can return arbitrary objects and the call still succeeds, so there's nothing more for us to do on these, I don't think: >>> class Foo:
... def __lt__(self, other):
... return Foo()
...
>>> Foo() < Foo()
<__main__.Foo object at 0x1031cca50> You could argue it's a bit of an antipattern to return a non-bool from these methods, but again, it's sort of a linter issue than something for a type checker to flag |
Yeah I think this would apply to at least |
Description
Dunder methods like
__bool__
,__len__
(and binary/compare?) should return a value that is assignable to what's expected by their "convention". We currently don't check this.The text was updated successfully, but these errors were encountered: