-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Should *args
narrow in type guards?
#14273
Comments
cc @erictraut as creator of pyright and typeguard PEP writer.
|
I have to admit that I hadn't considered the use of an Pyright's implementation happens to handle this case. If it's simple for this to be fixed in mypy, then it might be worth making the change. I think it's also fine for mypy's maintainers to say "this is undefined behavior, so don't use |
Alright. I suspect it would be somewhat simple to handle, but will have to check in a while -- it's very likely, though, that I'll end up leaving the TODO alone. I'll leave this issue open in case someone with actual say in mypy wants to leave their opinion :P |
While making a PR I found a
TODO
that goes along the lines of "is*args
support forTypeGuard
even worth it?"I want to approach this from a different perspective. Pyright supports this:
I'm ... not quite sure that should be allowed. Going strictly by the specification:
(PEP 647, emphasis my own)
Notice how it says first and argument (no s). (and the "passed as" sets up that we're talking about function signature, not how the function is called)
Anyways, given that:
*args
argument (like pyright)? all of them (which would allow more flexibility)?)Should this even be attempted in the first place? I'm in favor of removing the
TODO
.The text was updated successfully, but these errors were encountered: