Repository navigation
Better message when inferred variable type conflicts with later use #2529
Description
If you can come up with a better name for this issue, please let me know, this one is poor. The naming difficulty also lead to difficulty searching to see if this already existed, so apologies in advance if this is a duplicate issue.
When running this code through the typechecker:
from typing import Union, Dict, List
def g() -> List[Union[str, int]]:
x = ['a']
x += [1]
return x
def f() -> Dict[str, Union[str, int]]:
d = {'a': 'a'}
d['b'] = 1
return dI get this output:
test.py: note: In function "g":
test.py:4: error: List item 0 has incompatible type "int"
test.py:5: error: Incompatible return value type (got List[str], expected List[Union[str, int]])
test.py: note: In function "f":
test.py:9: error: Incompatible types in assignment (expression has type "int", target has type "str")
test.py:10: error: Incompatible return value type (got Dict[str, str], expected Dict[str, Union[str, int]])
With both these functions, mypy is assuming the type on assignment, then having type errors due to conflicts with the explicitly declared return type.
Surely there should be a way to correctly infer the original type based on the return type?
Activity
JukkaL commentedon Dec 7, 2016
Mypy infers types roughly from top to bottom. This usually makes reasoning about inferred types easier and the implementation is also relatively straightforward. However, there are cases like your example this has undesirable results.
You can add a type annotation to make the error go away:
Modifying type inference to take the return type into consideration in cases like this would be hard and would complicate the relatively simple and predictable (once you understand a few principles) model that mypy currently uses. However, it might be useful to detect some cases like this and give a better error message. Potential better message:
JukkaL commentedon Dec 7, 2016
As it's unlikely that type inference will change for now, I'll update the title to consider a better error message.
[-]Variable assignment assumes a type that might conflict with later explicit declaration[/-][+]Better message when inferred variable type conflicts with later use[/+]TRManderson commentedon Dec 9, 2016
If #2542 and #2543 get merged I've got a not-so-nice PR to make that includes this kind of error message (without the suggestion, though, I'm still working on that)
quartox commentedon May 23, 2017
I will take a look at this.
quartox commentedon May 23, 2017
Should this note only cover the case when the object type conflicts with the return type or should it also cover the following:
which currently only outputs
I am planning on proceeding with only enhancing the message when it conflicts with the return and not cover the above case.