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 python/typing#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.
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.
Activity
gvanrossum commented on Sep 13, 2016
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.
elazarg commented on Sep 20, 2016
Now I believe that this is another incarnation of overload python/typing#253 and therefore #1941 and the others mentioned there. I cannot base this claim though.
wsanchez commented on Dec 16, 2016
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.
wsanchez commented on Dec 16, 2016
(or give up with a warning if the matrix is too large)
stefanuddenberg commented on Jun 18, 2018
I've encountered this bug most recently in version 0.610. A fix would be much appreciated!
ilevkivskyi commented on Jun 18, 2018
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.
davidlowryduda commented on Jun 26, 2018
I have also just encountered this bug (or rather, an equivalent bug concerning Union[int, complex] + Union[int, complex].
Michael0x2a commented on Jul 21, 2018
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.
Add support for operators with union operands
Add support for operators with union operands (#5545)