You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Mypy fails on Union[float, int] + Union[float, int] #2128
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 commentedon 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 commentedon 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 commentedon 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
mypyfor code quality checks, and this check is clearly incomplete/broken.wsanchez commentedon Dec 16, 2016
(or give up with a warning if the matrix is too large)
stefanuddenberg commentedon Jun 18, 2018
I've encountered this bug most recently in version 0.610. A fix would be much appreciated!
ilevkivskyi commentedon Jun 18, 2018
Here is my diagnosis, mypy first asks "What is the signature of
__add__when accessed onUnion[int, float]?" Looking at typeshed, this results inUnion[int -> int, float -> float], then mypy typechecks the callUnion[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 checkfloat.__add__(Union[int, float]), be satisfied, then checkint.__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 commentedon Jun 26, 2018
I have also just encountered this bug (or rather, an equivalent bug concerning
Union[int, complex] + Union[int, complex].Michael0x2a commentedon 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)