mypy doesn't recognize incompatible type in Dict

[etibger]

On windows,

python --version
Python 3.5.2

with the following mypy_bug.py:
from typing import Dict

CHESSDICT = {} # type: Dict[str, int]
CHESSDICT.update({("a", 1): "Rook"})
CHESSDICT.update({(0, 0): "Rook"})
for key in CHESSDICT:
print('position {0}, figure {1}'.format(key, CHESSDICT[key]))

python -m mypy -v .\mypy_bug.py
LOG: Mypy version 0.4.6
LOG: Parsing .\mypy_bug.py (mypy_bug)
LOG: Parsing C:\Users\user\venv\lib\mypy\typeshed\stdlib\3\typing.pyi (typing)
LOG: Parsing C:\Users\user\venv\lib\mypy\typeshed\stdlib\3\builtins.pyi (builtins)
LOG: Parsing C:\Users\user\venv\lib\mypy\typeshed\stdlib\3\sys.pyi (sys)
LOG: Parsing C:\Users\user\venv\lib\mypy\typeshed\stdlib\3\abc.pyi (abc)
LOG: Parsing C:\Users\user\venv\lib\mypy\typeshed\stdlib\3\types.pyi (types)
LOG: Parsing C:\Users\user\venv\lib\mypy\typeshed\stdlib\3_importlib_modulespec.pyi (_importlib_modulespec)
LOG: Loaded graph with 7 nodes
LOG: Found 2 SCCs; largest has 6 nodes
LOG: Processing SCC of size 6 (_importlib_modulespec types abc typing sys builtins) as inherently stale
LOG: Processing SCC singleton (mypy_bug) as inherently stale
LOG: No fresh SCCs left in queue
LOG: Build finished in 0.579 seconds with 7 modules, 1708 types, and 1 errors
mypy_bug.py:5: error: List item 0 has incompatible type "Tuple[Tuple[int, int], str]"

The line no 5 is recognised correctly as incompatible with Dict[str, int]
But line no 4 is not recognised, but in my opinion Dict[str, int] != Dict[Tuple[str, int], str]

[gvanrossum]

Thanks! I can repro this. It seems that because dict.update() is overloaded to accept either Dict[key, value] or Iterable[Tuple[key, value]], when it finds no match for the Dict overload, it uses the Iterable overload, and iterating over a dict produces its keys.

I suspect this is going to be somewhat tricky to fix without special-casing in mypy. @JukkaL, thoughts?

[JukkaL]

Perhaps overload resolution in mypy is wrong here. We could perhaps choose the target overload variant using erased types only (e.g. Dict[Any, Any] instead of Dict[str, int]). I think that that's how it used to behave, but maybe that would cause other sorts of trouble elsewhere. At least it's worth considering. If that doesn't work, then we'd probably have to special case, which is not entirely crazy for such an important class, but it's not a high-priority thing as this is a pretty unusual edge case.

[dmoisset]

From what I saw this is unrelated to the overload of dict.update and has to do with the confusing error message shown in dict displays (which always adds an extra Tuple). I added a PR (#3100) to fix the error message and what you see in this example makes more sense