Try to fix problems caused by in-place modification of typevar defaults#19382
Closed
sterliakov wants to merge 3 commits into
Closed
Try to fix problems caused by in-place modification of typevar defaults#19382sterliakov wants to merge 3 commits into
sterliakov wants to merge 3 commits into
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Contributor
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
ilevkivskyi
added a commit
that referenced
this pull request
Nov 20, 2025
…20139) Fixes #19185. Fixes #19186. Replaces #19382 (not closing that yet, need to extract another part related to `applytype` from there to another PR). When a `TypeVar` defaults to another `TypeVar`, that default should already be in scope. Fortunately we already analyze them in the correct order, so the active scope has all the necessary information. This fixes the namespace drift problem because the bound typevars are already adjusted to use the correct namespace, and we do not need to touch their global definitions. I am not super happy about making TypeVarLikeScope impure here - any suggestions? Would passing `self.msg` to every `bind_new` call look saner? --------- Co-authored-by: Ivan Levkivskyi <levkivskyi@gmail.com>
ilevkivskyi
added a commit
to ilevkivskyi/mypy
that referenced
this pull request
May 21, 2026
) Fixes python#19192 Fixes python#20027 Fixes few TODOs in tests (don't know if there are relevant issues) Closes python#19382 Core idea is simple: don't do bizarre things :-) More precisely, instead of various in-place modifications (which is a big no-no for types), simply expand defaults iteratively as we build the environment for the type. Couple additional things: * Update defaults in `freshen_function_type_vars()` this is required for consistency when updating `TypeVarId`s. * Use `fix_instance()` in `checkexpr.py` for type applications. This will apply _all_ type arguments in cases like `x = Foo[int](...)`. The PEP and the spec say this is how it should be.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #19186. Fixes #19185. Fixes #19192. Fixes behavior in #14851 (comment) (note that assert_type should fail with bare class, it is still generic until actually used unsubscripted).
I do not know yet whether these changes are actually valid. Let's check the primer output and run all tests first.