Don't truncate Tuple, Union, and generic types in error messages

[gvanrossum]

This gives the expected error::

from typing import List, Tuple
x = [
    ('', [''], 0),
    ]  # type: List[Tuple[str, List[str], str]]

Error::

z.py, line 2: List item 1 has incompatible type "Tuple[str, List[str], str]"

But this shortens the type to just 'tuple'::

from typing import List, Tuple
x = [
    ('', '', [''], 0),
    ]  # type: List[Tuple[str, str, List[str], str]]

Error::

z.py, line 2: List item 1 has incompatible type tuple

[iankronquist]

@JukkaL
Is this bug still an issue? I ran the above code and got this output:

$ mypy z.py
z.py, line 2: List item 1 has incompatible type "Tuple[str, str, List[str], int]"

[rwbarton]

There's some logic to avoid printing out really long types. 655eddf#diff-7739b07c7ae4561e51cbb36f31984c90L188 increased the limit, but you can still reach the limit by adding a couple more fields to the tuple.

Personally I would prefer always seeing the full type; the details might matter to the message (like here, with str vs. int in the last component), but even when they aren't directly relevant (like if the declared type of the list was something completely different like List[bool]) seeing the contents of the tuple is often a valuable clue to understanding where the type came from and what you did wrong to get it instead of the type you expected.

[gvanrossum]

Yeah, I've encountered a few cases where the truncated message ended up being pure misdirection.

[JukkaL]

I've been bitten by this as well. In retrospect, truncating long types now seems like a bad idea in general. It might still be occasionally useful in cases like expected Tuple[...], got int, where the truncated form would contain enough information about the types to highlight the difference, but the benefits would be marginal and not certain. Maybe just leave out the type truncation -- we can reconsider and add it back if it results in confusing messages.

There are other options such as run length encoding long tuples (for example, Tuple[str, ..., str] (9 items) but until we encounter cases where these would be helpful it's uncertain whether these would be worth implementing.

Another option for cases where we display an expected and an actual type would be to run a more complete type diff algorithm and highlight the differences (e.g., expected tuple with length 9, got tuple of length 8). Even then we could display additional lines with the full types. Hypothetical example:

x.py:123: error: Argument 1 to "f" has incompatible type tuple (length 9); expected tuple (length 8)
x.py:123: note:     Actual type:   Tuple[int, int, int, int, int, int, int, int, int]
x.py:123: note:     Expected type: Tuple[int, int, int, int, int, int, int, int]

By aligning the types it would be easier to see how they are different in case they are similar but not compatible.

[gnprice]

Current status: when the full, untruncated rendering of the type is over 40 characters, we abbreviate it to look like tuple(length 6). The logic is in the format_simple method in https://github.com/python/mypy/blob/master/mypy/messages.py .

[ddfisher]

This is something that would/should be fixed as part of #1582, if it's not fixed sooner.

[gnprice]

I expanded the scope of this issue slightly in its title. The same format_simple method in mypy/messages.py applies very similar treatment to Union types and generic types as it does to Tuple -- search for len in the body of the function :-P -- and I think we should stop truncating in all those cases for basically the same reasons.

A nice follow-up would be to present a diff like @JukkaL suggests in a comment above, but that should come separately after making the simpler change to stop truncating.

[gvanrossum]

For unions I just upped the truncation limit from 40 to 400. That should cover most cases. f67bdbd