Should use fully qualified names in error messages

[marienz]

When mixing classes with the same name defined in different modules, it's possible to generate error messages like this that are a little difficult to decipher:

/tmp/my.py:19: error: Argument 1 to "add_done_callback" of "Future" has incompatible type "Callable[[Future[T]], None]"; expected "Callable[[Future[T]], Any]"                                                                                 
/tmp/my.py:20: error: Argument 1 to "add_done_callback" of "Future" has incompatible type "Callable[[Arg(Future[T], 'source')], None]"; expected "Callable[[Future[T]], None]"

The actual problem was that the "Future" on one side of the error was from a different module. It's especially difficult to spot because of the unrelated superficial differences: I assumed there was some kind of significance to one side having a named Arg while the other doesn't.

I ran into this while writing something similar to asyncio.wrap_future, which converts from one library's Future class to another's, and getting the two mixed up in my type annotations.

Including the fully qualified class names would have made the error message much more obvious.

[ilevkivskyi]

I am sure this is a duplicate, but can't find an original issue. Anyway this is is an actual usability issue, and don't know how to fix it without making all errors more bulky.

[marienz]

I was expecting this to be already filed too, but couldn't find an existing issue to subscribe to either.

It'd be nice to only include the fully qualified names if the error message references two distinct types with names that are otherwise identical, but (without having looked at the code) I assume that's really annoying to implement...

[Daenyth]

Maybe when two non-equal types in the same error line have the same display name, add a distinguishing mark, like:

/tmp/my.py:19: error: Argument 1 to "add_done_callback" of "Future{2}" has incompatible type "Callable[[Future{2}[T]], None]"; expected "Callable[[Future{1}[T]], Any]"  
note: Future{1} is foo.bar.Future
note: Future{2} is blah.quoz.Future

[JukkaL]

We already have a way to do something related: there's format_distinctly in mypy/messages.py that tries to automatically increase the verbosity of string formatting until two types have different string representations. We could perhaps update it to handle this case as well.

Here is one idea:

• Implement a helper that returns the fully-qualified names of all (class) types included in a type.
• Update type-to-string formatting methods to allow taking an optional set of type names that should be given fully qualified names when formatted (the default would be to use short names).
• format_distinctly will check if there are two different component types with the same short name but a different full name. If this is the case, use full names for these types only.

[amarshall]

Additionally it’d also be helpful when it’s a name that’s not imported. Sometimes it’s challenging to know where the type is even from.