Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wrong dict type inference for various types #3814

Closed
yedpodtrzitko opened this issue Aug 8, 2017 · 1 comment
Closed

wrong dict type inference for various types #3814

yedpodtrzitko opened this issue Aug 8, 2017 · 1 comment

Comments

@yedpodtrzitko
Copy link
Contributor

Hi,
not sure if I got it right, but it looks like the type of dict in example below is incorrectly inferred:

def diff_types(foo, bar):
    # type: (int, str) -> None
    pass

params = dict(foo=1, bar='bar')
diff_types(**params)

output for mypy --py2 ./foo.py

foo.py:7: error: Argument 1 to "diff_types" has incompatible type **Dict[str, object]; expected "int"
foo.py:7: error: Argument 1 to "diff_types" has incompatible type **Dict[str, object]; expected "str"

adding a generic type like this params = dict(foo=1, bar='bar') # type: dict solves the issue.

Changing the function's signature to have both params the same type (eg. str) (+ changing the params accordingly) obviously solves the issue.

Would it be possible to make it work without explicitly specifying the # type: dict there?

Cheers.

mypy version 0.521

@JukkaL
Copy link
Collaborator

JukkaL commented Aug 9, 2017

The annotation solves the issue since # type: dict is equivalent to # type: Dict[Any, Any]. Mypy doesn't infer this type automatically since mypy let's you do anything with Any values, which potentially causes mypy to miss some real errors in your code. The inferred type Dict[str, object] is technically correct and type safe, but typically not very useful.

There is a clear usability problem. A potential way to improve the situation would be to explicitly require an annotation for params. I created a new issue #3816 for this. Closing this issue since the current behavior is technically correct, even if it's confusing.

@JukkaL JukkaL closed this as completed Aug 9, 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

No branches or pull requests

2 participants