Join GitHub today
Fix incorrect tracking of "final" Instances #6763
This diff makes three changes: it fixes a bug where we incorrectly track "final" Instances, does some related refactoring, and finally modifies tuple indexing to be aware of literal contexts.
Specifically, here is an example of the bug. Note that mypy ignores the mutable nature of
To fix this bug, I decided to adjust the variable assignment logic: if the variable is non-final, we now scan the inferred type we try assigning and recursively erase all set
This change ended up making the
I suspect this change will also result in some nice dividends down the road: defaulting to preserving the underlying literal when inferring expression types will probably make it easier to add more sophisticated
In the process of implementing the above two, I discovered that "nested" Instance types are effectively ignored. So, the following program does not type check, despite the
This is mildly annoying, and also made it slightly harder for me to verify my changes above, so I decided to modify
(Actually, I found I could move this check directly into the 'accept' method instead of special-casing things within
ilevkivskyi left a comment
I like this idea, here are some thoughts/questions:
@ilevkivskyi -- I renamed the field as suggested.
One complication of the rename is that it potentially invalidates any existing mypy caches -- we now look for the "last_known_value" entry in the cache, instead of "final_value".
Maybe this is too disruptive, especially during the pycon sprints? If you want, I can partially revert the changes I made to the Instance deserialization/serialization methods so they continue using "final_value" and submit a PR for those two methods closer to the next mypy release.
Regarding invariance -- I don't think it'll cause an issue because we always erase this field when binding Instances to a TypeVar. I think the existing
I also added
Or maybe you were thinking of something else regarding invariance?
Regarding mypyc -- I'll start work on a PR to make any necessary changes now.
I don't think it is something worth worrying about, mypy normally ignores the cache from another mypy version anyway.
Nothing specific, just wanted to double-check that we have a good coverage for this.
OK, I think this can be merged now, because mypyc uses a pinned mypy commit hash. So your PR to mypyc should combine a pin move plus the related updates to mypyc code.