Fix sentinel identity loss through generic substitution and inference - #21888
Open
edgarrmondragon wants to merge 1 commit into
Open
Fix sentinel identity loss through generic substitution and inference#21888edgarrmondragon wants to merge 1 commit into
edgarrmondragon wants to merge 1 commit into
Conversation
A sentinel's only way to identify itself is via its attached literal value, unlike e.g. enum members whose class already carries identity. That literal was being unconditionally stripped both when a TypeVar was substituted with a sentinel instance (e.g. `dict.get`'s overloaded default parameter) and when inferring the type of a plain variable assignment, collapsing every sentinel down to the same uninformative `sentinel` type. Preserve it in both cases. Fixes python#21866 Follow-up from python#21647 Signed-off-by: Edgar Ramírez Mondragón <edgarrm358@gmail.com>
edgarrmondragon
commented
Aug 24, 2026
|
|
||
| assert_type(ALIAS, sentinel) | ||
| # The value still identifies as the same sentinel... | ||
| assert_type(ALIAS, MISSING) |
Contributor
Author
There was a problem hiding this comment.
I think this is more useful now and still in line with #21647 (comment) and the spec:
https://typing.python.org/en/latest/spec/special-types.html#sentinels
Contributor
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
edgarrmondragon
marked this pull request as ready for review
August 24, 2026 19:19
cdce8p
approved these changes
Aug 24, 2026
cdce8p
left a comment
cdce8p
left a comment
Collaborator
There was a problem hiding this comment.
Thanks for looking into it @edgarrmondragon! The changes make sense and look good to me.
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.
A sentinel's only way to identify itself is via its attached literal value, unlike e.g. enum members whose class already carries identity. That literal was being unconditionally stripped both when a
TypeVarwas substituted with a sentinel instance (e.g.dict.get's overloaded default parameter) and when inferring the type of a plain variable assignment, collapsing every sentinel down to the same uninformativesentineltype. Preserve it in both cases.Fixes #21866
Follow-up from #21647