Use type context to infer type of empty collections in and/or expressions #6572
Labels
bug
mypy got something wrong
false-positive
mypy gave an error on correct code
priority-2-low
topic-type-context
Type context / bidirectional inference
Comments
|
x = [] # mypy would complain here, but assume we ignore it, so 'x' is 'List[<nothing>]'
y: List[str] = x # this is dangerous
y.append('boom')
z: List[int] = x
z[0] + 42 # TypeError hereInstead mypy should use the outer type context to infer the correct type of an empty collection. I will edit the title accordingly. |
|
Also this is low priority since it may be tricky to implement one can instead simply write: def func(lst: Optional[List[int]] = None) -> None:
if lst is None:
lst = [](which is also more readable IMO) |
|
It might be reasonable to make |
|
Cannot reproduce any of these false-positive errors on mypy 0.941; mypy seems to cope with these fine now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Underlying issue: for any generic type, mypy considers GenType[] and GenType[X] to be incompatible classes. These should instead be considered to be of type GenType[X]. (Observed with mypy 0.670 / Python 3.6, no flags passed to mypy)
To illustrate why, consider two common Python idioms where this happens. One is in a function declaration, where None is passed as a default value rather than a class-scoped mutable variable:
This is reported as an error, "Incompatible types in assignment (expression has type "Union[Set[str], Set[]]", variable has type "Optional[Set[str]]")"
Likewise, if an abstract superclass declares a method which yields an iterator,
Because the abstract declaration passes, it is actually returning an optional iterator (which mypy correctly understands). Callers of the abstract method then cope with this easily:
which yields the same error as above, or
which fails with "error: "yield from" can't be applied to "Union[Iterator[type], List[]]".
The expected behavior in all cases is no error: empty iterables should be considered to be valid instances of iterables of any type, without further annotation.
The text was updated successfully, but these errors were encountered: