Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork3.1k
Fix incorrect TypeVar default expansion order (Fixes #20336)#20343
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:master
Are you sure you want to change the base?
Fix incorrect TypeVar default expansion order (Fixes #20336)#20343
Uh oh!
There was an error while loading.Please reload this page.
Conversation
sterliakov left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Was this generated by some kind of LLM?
Please add a few testcases (at least from the original issue and from comments there).
ayushdoesdev commentedDec 1, 2025
Hi@sterliakov , no I took help but did code on my own because they were not able to help Ok I will add the test case |
According tomypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
ayushdoesdev commentedDec 1, 2025
@sterliakov something up with .mypy_cache? does it show previous output even after changes? |
sterliakov commentedDec 1, 2025
Mhm, you can run |
This PR fixes how mypy handles generic classes with default type parameters when they refer to themselves inside the class body. ItFixes#20336
Before this change, if you wrote something like:
mypy would show:
It ignored the fact that
Foo[Y, X]swaps the type variables.With this change, mypy now keeps the order that the user wrote:
The fix is in
fix_instanceinmypy/typeanal.py.It checks for cases where all the type arguments are the class’s own type variables (like
Foo[Y, X]) and skips the extra expansion step that was reordering them.