Repository navigation
Recent change to tuple constructor breaks subclasses of tuples #8275
Description
A recent change to the tuple.__new__ method in builtins.pyi introduced an overload:
@overload
def __new__(cls) -> tuple[()]: ...This overload is problematic for classes that derive from specialized tuples.
class MyTuple(tuple[int, str, str]):
...
x = MyTuple()
reveal_type(x) # tuple[()] !!!!Because of this overload, the wrong type is evaluated.
I think this overload should return Self, not tuple[()]. Admittedly, that doesn't produce the ideal type evaluation for tuple(). It produces tuple[Any, ...] rather than tuple[()].
Activity
AlexWaygood commentedon Jul 12, 2022
I feel like maybe a type checker should disallow this snippet. This is what happens at runtime:
Perhaps type checkers should disallow calls to subclasses of specialised tuples unless
__new__has been overridden?JelleZijlstra commentedon Jul 12, 2022
@AlexWaygood the runtime type of
MyTuple()is in factMyTuple. I don't see why type checkers should disallow that.This change is from #7454. I already brought up this possible issue, but for whatever reason mypy doesn't infer the wrong type for subclasses in this case. Given that it causes a regression for pyright, I'm fine with reverting it.
AlexWaygood commentedon Jul 12, 2022
The runtime type is
MyTuple, yes, but it's not a subtype oftuple[int, str, str]. My concern is about situations like this:That feels pretty unsafe to me.
But I'm fine with reverting #7454 for now; I agree that it doesn't bring much benefit.