[ty] Extend tuple __len__ and __bool__ special casing to also cover tuple subclasses

[AlexWaygood]

Summary

This PR (a collaboration with @ntBre) extends our existing __len__ and __bool__ special casing so that it also works with tuple subclasses. I.e., for a class like Foo here, we will now understand that instances of Foo are always truthy, and that calling len() on an instance of Foo will always return Literal[1]:

class Foo(tuple[int]): ...

The approach taken is to synthesize __bool__ and __len__ class attributes on the generic alias object tuple[int]. tuple[int].__bool__ is inferred as a function-like Callable type with signature (self: tuple[int], /) -> Literal[True]; a similar approach is taken for tuple.__len__. This means that the correct signature for these methods is naturally inherited by subclasses; it means that protocol subtyping will work correctly for these subclasses; and it means that once we have implemented the Liskov Substitution Principle, unsound overrides of these methods on tuple subclasses will be naturally detected by ty.

Test Plan

Mdtests

---

Co-authored-by: Brent Westbrook 36778786+ntBre@users.noreply.github.com

[github-actions]

mypy_primer results

No ecosystem changes detected ✅
No memory usage changes detected ✅

[MatthewMckee4]

Should this not also be a Liskov violation?

[MatthewMckee4]

Okay i guess its not a Liskov violation, but should we not complain at this?

[MatthewMckee4]

Ah sorry I retract this, my bad.

[MatthewMckee4]

Okay changed my mind slightly

def foo(x: tuple[int, ...]):
    if x:
        # Should we not also be able to say len(x) != 0
        # *This should pass
        assert len(x) != 0

foo(Baz(()))

In rust if you have a len function clippy tells you to have an is_empty function and auto generates to self.len() == 0.

This maybe isn't relevant, but it seems like we shouldn't allow override of just __bool__. I'm not sure where else to go with this to be honest.

[AlexWaygood]

No, I think that's a great point! It seems like in general, as part of our Liskov implementation, we should probably enforce that __bool__ and __len__ are never overridden to be inconsistent with each other on any Sequence subtype. I think otherwise this could indeed cause us to make incorrect assumptions, not just regarding tuples

[MatthewMckee4]

Cool thanks, so in this case we could emit a diagnostic saying that there should be a ’len’ method that returns ’int & ~Literal[0]’ (or something like that).

[AlexWaygood]

Hmm, not sure about that specifically -- I guess I'm not sure we should emit an error on this specific tuple subclass. It seems a bit pedantic -- just because the __len__ method is annotated as returning int doesn't mean that the class is violating the contract of Sequences. It just means that we haven't been given enough information to verify; I think it's probably better to steer clear of false positives in that situation and assume the user knows what they're doing. It's not the goal of ty to catch every possible error that a user could make.

But I do think it's worth emitting errors on these classes, because here we do have enough information to say that __len__ and __bool__ are inconsistent with each other:

from collections import Sequence
from typing import Literal

class Foo(Sequence[int]):
    def __len__(self) -> Literal[0]:
        return 0

    def __bool__(self) -> Literal[True]:
        return True

class Bar(Sequence[int]):
    def __len__(self) -> Literal[3]:
        return 3

    def __bool__(self) -> Literal[False]:
        return False

Even here, though, it's questionable whether this is a typing error or more something that's in the domain of a type-aware linter to check. (That doesn't mean that it wouldn't be a useful rule -- I think it would! But it might not be in the core purview of ty right now -- it might be more something for the future, when we start to use ty to power type-aware lint rules in Ruff.)

So I guess I feel like you're raising a great point in general, but that for these specific cases we probably shouldn't emit errors, and even if we should it maybe shouldn't be ty itself that emits these errors but maybe a type-aware linter built on top of ty :-)

[sharkdp]

Very nice!