-
-
Notifications
You must be signed in to change notification settings - Fork 30.7k
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
gh-102615: Fix type vars substitution of collections.abc.Callable
and custom generics with ParamSpec
#102681
Conversation
…ble` and custom generics with `ParamSpec`
I encountered another bug, the
EDIT: THIS MIGHT NOT BE A BUG, AS ITS AN INVALID USE. PLEASE IGNORE THIS @sobolevn |
@Fidget-Spinner I would like to move all I've only touched params substitution here. |
Wait a moment, this is not about >>> ca.Callable[[int, P], int][P].__args__
(<class 'int'>, ~P, <class 'int'>)
>>> ca.Callable[[int, P], int][P][int].__args__
(<class 'int'>, (<class 'int'>,), <class 'int'>) |
Funny thing, I just removed this code from if (len(self.__parameters__) == 1
and _is_param_expr(self.__parameters__[0])
and item and not _is_param_expr(item[0])):
item = (item,) All tests still pass :) 🤯 |
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.
I think the runtime is correct in raising TypeError for these situations, actually: see #102615 (comment)
Maybe instead, we should focus on improving the error message, so that users get more specific feedback on why the substitution is being disallowed? Though if it adds too much complexity to the code, I probably wouldn't bother with it.
I am going to close this for now, I will add new tests in other PRs, because this one has a big unrelated history. |
I would prefer to create two PRs to fix #102615
Callable
and custom generics withParamSpec
list
instead oftuple
inrepr
of paramspec #102637 to change therepr