Better handling of Any/object in variadic generics #18643
Merged
Conversation
This file contains 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
This comment has been minimized.
This comment has been minimized.
|
Hm, this exposed an inconsistency in instance vs type variable join. Let me try a principled first, but if there will be fallout, I will limit it to the variadic cases only. |
|
Actually, after all I decided not to open this can of worms, let's limit the fix for uncovered inconsistency to variadic generics. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Pinging on review here, if there are no objections I will be merging this soon. |
JukkaL
approved these changes
Feb 12, 2025
| def join(x: T, y: T) -> T: ... | ||
| def test(xs: tuple[Unpack[Ts]], xsi: tuple[int, Unpack[Ts]]) -> None: | ||
| a: tuple[Any, ...] | ||
| reveal_type(join(xs, a)) # N: Revealed type is "builtins.tuple[Any, ...]" |
There was a problem hiding this comment.
Also try the opposite argument order (join(a, xs)) here and below?
There was a problem hiding this comment.
OK, added symmetric check for each pair.
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
ericmarkmartin
pushed a commit
to ericmarkmartin/mypy
that referenced
this pull request
Feb 19, 2025
Fixes python#18407 Fixes python#17184 Fixes python#16567 There are three things here: * Allow erased variadic callables with non-empty prefix to be supertypes of the non-erased ones. This relaxes a bit callable subtyping in general, but IMO this makes sense, people who want to be strict should simply use `*args: object` instead. An alternative would be to track erased variadic callables explicitly, which is ugly and fragile. * Add important missing case in `subtypes.py` for `*Ts` w.r.t. `Any`/`object` that handles similar situations for variadic instances and tuples (here however there is nothing special about `Any` vs `object`). * I also fix inconsistency in join uncovered by the above two. The changes in `expandtype.py` are no-op, I just noticed potential danger while playing with this, so wanted to highlight it with comments for the future.
ericmarkmartin
pushed a commit
to ericmarkmartin/mypy
that referenced
this pull request
Feb 19, 2025
Fixes python#18407 Fixes python#17184 Fixes python#16567 There are three things here: * Allow erased variadic callables with non-empty prefix to be supertypes of the non-erased ones. This relaxes a bit callable subtyping in general, but IMO this makes sense, people who want to be strict should simply use `*args: object` instead. An alternative would be to track erased variadic callables explicitly, which is ugly and fragile. * Add important missing case in `subtypes.py` for `*Ts` w.r.t. `Any`/`object` that handles similar situations for variadic instances and tuples (here however there is nothing special about `Any` vs `object`). * I also fix inconsistency in join uncovered by the above two. The changes in `expandtype.py` are no-op, I just noticed potential danger while playing with this, so wanted to highlight it with comments for the future.
x612skm
pushed a commit
to x612skm/mypy-dev
that referenced
this pull request
Feb 24, 2025
Fixes python#18407 Fixes python#17184 Fixes python#16567 There are three things here: * Allow erased variadic callables with non-empty prefix to be supertypes of the non-erased ones. This relaxes a bit callable subtyping in general, but IMO this makes sense, people who want to be strict should simply use `*args: object` instead. An alternative would be to track erased variadic callables explicitly, which is ugly and fragile. * Add important missing case in `subtypes.py` for `*Ts` w.r.t. `Any`/`object` that handles similar situations for variadic instances and tuples (here however there is nothing special about `Any` vs `object`). * I also fix inconsistency in join uncovered by the above two. The changes in `expandtype.py` are no-op, I just noticed potential danger while playing with this, so wanted to highlight it with comments for the future.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 #18407
Fixes #17184
Fixes #16567
There are three things here:
*args: objectinstead. An alternative would be to track erased variadic callables explicitly, which is ugly and fragile.subtypes.pyfor*Tsw.r.t.Any/objectthat handles similar situations for variadic instances and tuples (here however there is nothing special aboutAnyvsobject).The changes in
expandtype.pyare no-op, I just noticed potential danger while playing with this, so wanted to highlight it with comments for the future.