-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Regression in determining return type of zip() on tuples #4226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
We should probably move this to typeshed, I think mypy is doing the right thing here. mypy will usually pick the first matching variant and complicating that logic too much will make mypy unpredictable in ways that are bad for users. We could patch the situation by adding even more overloads (and removing a few of the longer heterogeneous overloads added in #3830). I think the following could actually work well in practice (it should make both the above and the original python/mypy#8454 work):
But given that the return type is a lie and that the original patch evidently caused issues I didn't foresee, maybe we should just revert #3830 Would appreciate opinions! |
OK, I am moving this issue to typeshed now. |
I don't think there is an easy solution. Reverting would fix my use case, but people using Tweaking overlapping rules, as @hauntsaninja proposed above, might work for small inputs, but I think any star rule will be matching too much and forcing the types to Having more advanced rules for handling overlapping overload declarations is likely to indeed get unpredictable if it ends up being some kind of scoring system. And I can't think of anything simpler that still solves the issue. A special case or plugin in mypy specifically for |
The zip change also caused a performance regression in mypy (python/mypy#9016). Maybe reverting is the right call? The old behavior maybe caused fewer issues. |
I also got a problem with that and opened a question on SO. |
staticdev's issue is unrelated, see python/mypy#9048 We reverted #3830 in #4254, so mthuurne's issue should be fixed. If more people report issues like python/mypy#8454, we could reconsider the overloads or maybe preferably write a mypy plugin. |
On the following code:
mypy 0.770 will output:
while mypy 0.780 will output:
The output from 0.770 is both more correct (since the
zip
object is not a tuple) and more useful (since the types of the elements are known).The fix for python/mypy#8454 adds additional overloaded definitions for
zip(*...)
in typeshed, which in itself is useful. However, for some reason mypy seems to prefer the new 'star' definitions to the older and more correct 'non-star' definitions, which causes this regression.The text was updated successfully, but these errors were encountered: