Fix special cases of kwargs + TypeVarTuple#17512
Fix special cases of kwargs + TypeVarTuple#17512A5rocks wants to merge 14 commits intopython:masterfrom
Conversation
|
cc @ilevkivskyi since I saw your changes w/r/t typevartuples when glancing over the merge conflicts. Maybe you'll have an idea of whether this Any-tuple thing is worth anything. |
A5rocks
changed the title
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
A5rocks
changed the title
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
With the simplification from removing Any-tuple this looks pretty damn clean. With no diff from mypy_primer I think we only need new tests and then it's pretty much ready to merge 🎉 |
|
Turns out I can't split anything off because the two fixes need each other for any visible effect. |
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
|
Would be lovely to get this merged, but it appears we've gotten merge conflicts that need resolved @A5rocks |
|
I've made a better version of this at #18958 |
3 participants
Fixes #16522. This PR adds special casing for TypeVarTuple inference in the face of kwargs, though I believe the general case requires providing multiple possible constraints (e.g. "constraint a OR constraint b OR constraint C") which either isn't possible or I don't know how to.
This PR also fixes the subtyping of e.g.
def f(a: int) -> Nonebeing a subtype ofdef g(*args: Unpack[tuple[Any, ...]]).TODO:
operator.callproducearg-typeerror with callables that take*args: Unpack[Ts]and >= 1 keyword argument #16662.