fix #16935 fix type of tuple[X,Y] expression

[urnest]

implement the mypy/checkexpr.py TODO: Specialize the callable for the type arguments
... so e.g. reveal_type(tuple[int, int]) gives expected
def (p0: tuple[builtins.int, builtins.int]) -> tuple[builtins.int, builtins.int]

... rather than
def [_T_co] (typing.Iterable[_T_co1] =) -> builtins.tuple[_T_co1, ...]

Fixes #16935

[stroxler]

Is this from an earlier iteration of the PR?

It seems to be unused in the current code, and we probably don't want to add abc to all the tuple tests if we can help it.

[urnest]

This is the first iteration of the PR...

I'd happily remove it, just not sure how (and I'm no expert, so don't take that as "can't"!):

checkexpr.py line 4849 (that I added) needs it... without adding the tuple.pyi import I get unit test failures like:
data: /home/xju/mypy/test-data/unit/check-type-aliases.test:1016:
...
File "/home/xju/mypy/mypy/checkexpr.py", line 4849, in apply_type_arguments_to_callable
self.chk.named_type("abc.ABCMeta"),
...
KeyError: 'abc'

... but maybe my checkexpr.py line 4849 is wrong or could be expressed differently? I chose that by looking at the result of CheckerPluginInterface.get_expression_type() for the expression "list[int]":
(Pdb) p expr_type
Overload(def () -> builtins.list[builtins.int], def (typing.Iterable[builtins.int]) -> builtins.list[builtins.int])
(Pdb) p expr_type.items[0]
def () -> builtins.list[builtins.int]
(Pdb) p expr_type.items[0].fallback
abc.ABCMeta
(Pdb) p type(expr_type.items[0].fallback)
<class 'mypy.types.Instance'>

... and somewhere I noticed that chk.named_type("abc.ABCMeta") appeared to produce exactly that:
(Pdb) self.chk.named_type("abc.ABCMeta")
abc.ABCMeta
(Pdb) type(self.chk.named_type("abc.ABCMeta"))
<class 'mypy.types.Instance'>

... thoughts/suggestions?

[stroxler]

Oh it's likely that I was mistaken here and it's actually needed, I'm also new to MyPy.

I suppose the import resolver determines which modules MyPy will parse, and that's why you hit an error without this line.

I didn't entirely understand why we need ABCMeta as a fallback either, but this is also related to me being new to MyPy.

[urnest]

mmm, I don't think ABCMeta is correct:

• in the list[int] case we want a function that returns a list[int], i.e. like def g() -> list[int]
• that is a specific instance of a function, so its fallback should be "function"
  ... I wonder what the fallback is for a plain function? Let's try:
  def ff(): pass
  ... for that pdb mypy shows that CheckerPluginInterface.get_expression_type() returns:

(Pdb) p expr_type
def () -> Any
(Pdb) p type(expr_type)
<class 'mypy.types.CallableType'>
(Pdb) p expr_type.fallback
builtins.function

... that makes more sense, yes?

I will try that out... might be a day or two...

[urnest]

... ok after a bit more digging I believe ABCMeta is correct:

• ff's Callable above has fallback builtins.function, and that is correct for ff, which is a just a function
• but ff is not a mypy "type object" Callable, and the mypy type of expression "tuple" must be a type object Callable; mypy uses Callable's fallback to distinguish (see mypy.types.Callable.is_type_obj() implementation)
• "int" gets fallback "builtins.type", I believe because its definition in builtins.pyi has no explicit base class
• "list" gets fallback "abc.ABCMeta", I believe because its definition in builtins.pyi has an abstract base class
• ... so "tuple" should get fallback "abc.ABCMeta" too because its definition in builtins.pyi has an abstract base class

... but I then realized that I can get the fallback from "tp" rather than looking it up, and doing that avoids needing to add abc.ABCMeta to test-data/unit/fixtures/tuple.pyi... so that is what I've done in commit [5bd1c4c]; I also removed the "p1" as param name, using None instead because that seems to be the convention for type object Callables

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[stroxler]

After getting rid of the explicit ABCMeta, this looks right to me, tests look good and the code change seems reasonable.

I'm not a maintainer, but approving because it may mean someone else can do a quick review sooner.