-
-
Notifications
You must be signed in to change notification settings - Fork 31.8k
gh-91162: Disallow tuple[T][*anything] #92255
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Oops, sorry - while implementing another PR, I realised this is probably going to conflict with something else we'll need to do in |
complexity to typing.py). This spec is currently being discussed at | ||
https://github.com/python/cpython/issues/91162. | ||
Note that not all the rules governing substitution behavior at runtime | ||
is codified in PEPs; the source of truth for these tests is the tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is codified in PEPs; the source of truth for these tests is the tests | |
are codified in PEPs; the source of truth for these tests is the tests |
@@ -876,6 +876,15 @@ def __repr__(self): | |||
return f'ForwardRef({self.__forward_arg__!r}{module_repr})' | |||
|
|||
|
|||
def _is_unpacked_type(x: Any) -> bool: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
def _is_unpacked_type(x: Any) -> bool: | |
def _is_unpacked_type(x: object) -> bool: |
Thanks for the quick review anyway Jelle :) I'll integrate those suggestions in the upcoming PR. |
We agreed in #91162 that unpacked type arguments should only be valid to generic aliases that can accept a variable number of arguments - that is, unpacked type arguments should only be valid to generic aliases with a TypeVarTuple in the type parameters.
@JelleZijlstra Could I ask you for review on this?
(This PR is based on #92249, so there are a couple of extra commits. See the latest commit for the one that's actually part of this PR. I think I should be able to effectively hide the changes from the extra commits once #92249 is merged - so we can start review on this PR now?)