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
Well, I have found another bug with union math in overloads, this time false negative:
fromtypingimportUnion, overload@overloaddeff(x: int, y: int) ->int: ...
@overloaddeff(x: object, y: str) ->str: ...
deff(x):
passx: Union[int, str]
y: Union[int, str]
f(x, y) # passes, but should fail because it never matches (str, int)
The problem is that make_simplified_union is used. On one hand this allows us to do unioning in more scenarios, on other hand it is dangerous for union counting in unioned args. I am not sure what to do. @Michael0x2a could you take care of this? (This is however not urgent, since this is a false negative.)
The text was updated successfully, but these errors were encountered:
Sorry, for overtaking, but I went ahead and now have a possible fix for this in a form of a change to a union math logic, so I am un-assigning you here, but I hope you will review my PR that I will open soon :-)
Fixes#5243Fixes#5249
Some comments:
* I went ahead with a slow but very simple recursive algorithm that treats all various complex cases correctly. On one hand it can be exponential, but on the other hand, the complexity will be bad _only_ if user abuses lots of unions
* I use a hack caused by the fact that currently most function inference functions pass argument _expressions_ instead of types, I left a TODO to use a more unified approach similar to multiassign_from_union
* It may look like there are many changes in tests, but actually there are not, the differences are because:
- Error messages now show the _first potentially matching_ overload (which is OK I think)
- Order of items in many unions turned to the opposite, apparently union `__repr__` is unstable.
Well, I have found another bug with union math in overloads, this time false negative:
The problem is that
make_simplified_union
is used. On one hand this allows us to do unioning in more scenarios, on other hand it is dangerous for union counting in unioned args. I am not sure what to do. @Michael0x2a could you take care of this? (This is however not urgent, since this is a false negative.)The text was updated successfully, but these errors were encountered: