Mypy: Mypy fails on `Union[float, int] + Union[float, int]`

Created on 13 Sep 2016  Â·  8Comments  Â·  Source: python/mypy

def add_value(a: Union[float, int], b: Union[float, int]) -> Union[float, int]:
    return a + b

Results in:

error: Unsupported operand types for + ("Union[float, int]" and "int")

Interestingly both

def add_value(a: Union[float, int], b: float) -> Union[float, int]:
    return a + b

and

def add_value(a: int, b: Union[float, int]) -> Union[float, int]:
    return a + b

work fine

bug false-positive priority-1-normal topic-union-types

Most helpful comment

Assigning myself -- I'm planning on making some fixes to operators in the near future, so I might as well look at this one too.

All 8 comments

That's definitely problematic. I suspect it's because we don't try all combinations of all unions involved in an expression. We should probably do better, although overuse of this could cause performance regressions.

Now I believe that this is another incarnation of overload https://github.com/python/typing/issues/253 and therefore #1941 and the others mentioned there. I cannot base this claim though.

Regarding @gvanrossum's comment: "overuse of this could cause performance regressions"…

Uh… code that's wrong isn't especially useful no matter how fast it is.

If it's too slow for whatever criteria, then it would be good to make this case a warning rather than an error, as false positives break CI builds that are trying to use mypy for code quality checks, and this check is clearly incomplete/broken.

(or give up with a warning if the matrix is too large)

I've encountered this bug most recently in version 0.610. A fix would be much appreciated!

Here is my diagnosis, mypy first asks "What is the signature of __add__ when accessed on Union[int, float]?" Looking at typeshed, this results in Union[int -> int, float -> float], then mypy typechecks the call Union[int -> int, float -> float](Union[int, float]), and correctly rejects it. It then falls back to __radd__ with obviously still no success. The flaw in this logic is that __add__ to __radd__ fallback happens _at runtime_, and to match this we need to allow fallback for some elements of a union. So the fix would be straightforward, first check float.__add__(Union[int, float]), be satisfied, then check int.__add__(Union[int, float]) and fallback to __radd__. @gvanrossum I don't think this will have any measurable performance implications.

Off-topic: it is sad to see many issues that have straightforward fixes, but we just don't have time to implement them, sigh.

I have also just encountered this bug (or rather, an equivalent bug concerning Union[int, complex] + Union[int, complex].

Assigning myself -- I'm planning on making some fixes to operators in the near future, so I might as well look at this one too.

Was this page helpful?
0 / 5 - 0 ratings