Ah, looks like CI is unhappy:

stdlib/builtins.pyi:788: error: Overloaded function signatures 1 and 2 overlap with incompatible return types [misc]

I see that most __new__ functions take cls: type[Self] as their first arg, but Self isn't subscriptable, so I wasn't sure how to specify that the return was Tuple[()] and not the default Tuple[Any]. Guidance here is appreciated 😅

It's unclear to me way mypy primer explodes, but I think it's related to isinstance checks, i.e. mypy thinks that isinstance(x, tuple) means that x is an empty tuple. Could you try reordering the overloads (and add a comment)?

Sure thing! added in d556d17; hope that comment is descriptive enough- I don't quite follow the issue.

Ah, I think I'm following now. Using tuple as a class not the result of an instantiation is the issue.

tuple should return Self, but tuple() should return Tuple[()]. I'm not sure how that's expressed in the interfaces correctly.

I'm not totally sure what's going on here myself. primer output looks much better, although it's weird that the remaining problems are in mypy itself. Maybe a mypy developer could look over this? Cc @JukkaL @hauntsaninja

I'm not sure either, will look into it soon.

I think the first error on config_files = tuple(map(os.path.expanduser, defaults.CONFIG_FILES)) is not specific to mypy's codebase and is a genuine false positive. The other two errors involve a custom mypy plugin that mypy uses on the mypy codebase; it's possible there's a bug in that plugin, but I'd need to investigate more to know what's going on.

Thanks for taking a look! Let me know if there's anything else I can do to be helpful.

Here, python/mypy#12319 will fix the errors from the plugin.

I unfortunately don't have a fix for the errors from config_files = tuple(map(os.path.expanduser, defaults.CONFIG_FILES)), but that's life.

I also filed python/mypy#12320 since it looks like a similar issue could crop up in other parts of mypy's codebase.

I'm not sure this change is worth it if we lose correct typing for subclasses of tuple. After class X(tuple), what does reveal_type(X()) do?

I'm not sure this change is worth it if we lose correct typing for subclasses of tuple. After class X(tuple), what does reveal_type(X()) do?

Empty tuples and tuple subclasses are both reasonably common, but I can't say I've ever seen an example of an empty tuple subclass instance. And for non-empty tuple subclass instances, we'll still have correct type inference, as that overload still returns Self. So I think it will probably be okay?

Seems like this change might also fix

• x = tuple() # type: Tuple[()] Incompatible types in assignment mypy#6283

Diff from mypy_primer, showing the effect of this PR on open source code:

mypy (https://github.com/python/mypy)
+ mypy/config_parser.py:182: error: Argument 1 to "map" has incompatible type overloaded function; expected "Callable[[str], AnyStr]"  [arg-type]

I'm not sure this change is worth it if we lose correct typing for subclasses of tuple. After class X(tuple), what does reveal_type(X()) do?

For both master and this PR, if I do mypy --custom-typeshed-dir on the following snippet, mypy yields the following result:

# test.py
class X(tuple): ...
reveal_type(X())  # Revealed type is "test.X"

So this doesn't seem to cause any regressions in that regard.