[ty] Emit diagnostic on tuple subclasses that override __eq__, __ne__ or __bool__ methods
#22150
+822
−91
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Diagnostic diff on typing conformance testsNo changes detected when running ty on typing conformance tests ✅ |
|
MatthewMckee4
commented
Dec 23, 2025
Comment on lines
4065
to
4074
| let mut diagnostic = | ||
| builder.into_diagnostic(format_args!("Unsafe override of method `{member}`")); | ||
|
|
||
| diagnostic.set_primary_message(format_args!( | ||
| "Unsafely overriding method `{member}` in a subclass of `tuple`" | ||
| )); | ||
|
|
||
| diagnostic.help(format!( | ||
| "Overriding `{member}` can cause unexpected behavior" | ||
| )); |
Contributor
Author
There was a problem hiding this comment.
I'm not sure how much we should explain why it is unsafe to override certain methods.
AlexWaygood
reviewed
Dec 23, 2025
Member
AlexWaygood
left a comment
There was a problem hiding this comment.
Thanks!
This looks like it's a bit too trigger-happy right now:
- I don't think we ever need to issue
unsafe-tuple-subclassfor a__len__override. Our existing Liskov Substitution Principle check takes care of that for us - For other methods such as
__bool__,__eq__, etc., I think we should avoid emitting this lint if the override would anyway cause us to emit a Liskov diagnostic. For something like this, we don't yet emit a Liskov diagnostic, but we should, so I don't think it should be covered by this check:class Foo(tuple[int]): __len__ = None
- I don't think we need to issue
unsafe-tuple-subclassfor a__bool__override unless we would infer the tuple superclass as either always-truthy or always-falsy. It's fine to override__bool__on a tuple subclass if the superclass has ambiguous truthiness; that won't violate any of our type-inference or narrowing assumptions elsewhere
AlexWaygood
reviewed
Dec 23, 2025
| } | ||
| } | ||
|
|
||
| const PROHIBITED_TUPLE_SUBCLASS_METHODS: &[&str] = &["__eq__", "__len__", "__bool__"]; |
Member
There was a problem hiding this comment.
other methods where we have special-cased behaviour for tuples are __lt__, __le__, __gt__, __ge__, __ne__, and __contains__. We probably need to ban overriding all of those too, unfortunately.
But as I said elsewhere, I think we can get rid of __len__ from this list (it's already covered by our Liskov checks). And there are many situations where overriding __bool__ on a tuple subclass should be fine.
We have very special-cased behaviour for __getitem__, but that should also be taken care of by our Liskov checks once we've finished implementing them, so I don't think you need to worry about __getitem__.
Member
There was a problem hiding this comment.
We have very special-cased behaviour for
__getitem__, but that should also be taken care of by our Liskov checks once we've finished implementing them, so I don't think you need to worry about__getitem__.
Ah, no, we do need to ban __getitem__ overrides too, I think, because our special casing for slices of tuples is not reflected in our synthesized __getitem__ overloads for specialized tuples.
And there is maybe one specific kind of __len__ override that we need to ban, which is __len__ being overridden on subclasses of "mixed" tuples. tuple[int, *tuple[int, ...]] means "a tuple of length at least one, but of potentially arbitrary length". Either of these overrides would not be caught by our Liskov checks, but both are clearly inconsistent with the tuple spec of the superclass:
from typing import Literal
class Foo(tuple[int, *tuple[int, ...]]):
def __len__(self) -> int:
return 2
class Bar(tuple[int, *tuple[int, ...]):
def __len__(self) -> Literal[2]:
return 2
MatthewMckee4
commented
Dec 23, 2025
MatthewMckee4
commented
Dec 23, 2025
Contributor
Author
|
Perhaps this can be repurposed to just cover |
Member
Sure! |
Contributor
Author
|
I maybe need some advice on diagnostic messages |
__eq__, __ne__ or __bool__ methods
AlexWaygood
reviewed
Dec 23, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Resolves astral-sh/ty#2171
Test Plan
Add
unsafe_tuple_subclass.mdmdtest file.