Support user defined variadic tuple types #15961
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
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
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 #15946
Note this actually adds support also for variadic NamedTuples and variadic TypedDicts. Not that anyone requested this, but since generic NamedTuples and generic TypedDicts are supported using the same mechanism (special aliases) as generic tuple types (like
class A(Tuple[T, S]): ...in the issue), it looked more risky and arbitrary to _not_support them.Btw the implementation is simple, but while I was working on this, I accidentally found a problem with my general idea of doing certain type normlaizations in
semanal_typeargs.py. The problem is that sometimes we can callget_proper_type()during semantic analysis, so all the code that gets triggered by this (mostlyexpand_type()) can't really rely on types being normalized. Fortunately, with just few tweaks I manged to make the code mostly robust to such scenarios (TBH there are few possible holes left, but this is getting really complex, I think it is better to release this, and see if people will ever hit such scenarios, then fix accordingly).