KEMBAR78
Add expected type in incompatible arg errors by miedzinski · Pull Request #3515 · python/mypy · GitHub
Skip to content

Conversation

miedzinski
Copy link
Contributor

Fixes #3499.

@miedzinski
Copy link
Contributor Author

There is one test failing because we are using format_simple everywhere. Should we skip expected types when dealing with FunctionLike or use format?

@gvanrossum
Copy link
Member

I'd start by not adding the "; expected blah" part to the error if format_simple() returns something empty.

@miedzinski
Copy link
Contributor Author

Do we really want to do that? Even without this patch mypy prints malformed messages, e.g.

(mypy-dev) ~/src/mypy [master] λ cat x.py 
from typing import Dict, Callable
def f() -> str:
    return 'foo'
d: Dict[str, Callable[..., int]] = {'bar': f}
(mypy-dev) ~/src/mypy [master] λ mypy x.py 
x.py:4: error: Dict entry 0 has incompatible type "str":

Notice the : at the end. And this doesn't happen with Callables only (which I understand may get long), but even with Type.

I'd go for using format method, just like MessageBuilder.invalid_index_type does.

@JukkaL
Copy link
Collaborator

JukkaL commented Jun 9, 2017

Using format seems reasonable to me.

Copy link
Member

@ilevkivskyi ilevkivskyi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This is almost ready to be merged, just two small comments.


# don't increase verbosity unless there is need to do so
from mypy.subtypes import is_subtype
if is_subtype(key_type, expected_key_type):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dict is invariant both in key and value types. Therefore is_subtype is probably not what you want here, maybe is_same_type from sametypes.py?

expected_value_type_str = self.format(expected_value_type)
else:
value_type_str, expected_value_type_str = self.format_distinctly(
value_type, expected_value_type)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add few new tests checking that this verbosity logic is followed correctly in different scenarios (taking into account mentioned invariance).

@ilevkivskyi
Copy link
Member

@miedzinski After some thinking, it looks like your initial design was actually right and it is OK to use is_subtype in the context of inference for dict literals. Also the added tests don't trigger the new error message (this is related). So that I would restore the is_subtype and rewrite the added tests like you proposed on gitter.

Sorry for troubles.

Copy link
Member

@ilevkivskyi ilevkivskyi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I understand the pre-release code freeze is over, so that I will merge this when tests pass.

@ilevkivskyi ilevkivskyi merged commit c8bfb65 into python:master Jul 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants