-
-
Notifications
You must be signed in to change notification settings - Fork 1.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
Fallback overloads for literal argument #5493
Comments
Seems like mypy doesn't use our |
I presume that the In most overloads that provide this fallback, the return type for the non-literal variant is not a union but an This fallback eliminates a class of false positive errors, so I see some utility in it. I guess it depends on whether you want to force typing strictness on all typeshed users or you want to be "looser" and avoid false positive errors. I can see arguments in favor of both approaches, but my guess is that the majority of Python developers would vote for reducing false positives over being ultra strict. |
In mypy, basically anything that comes from a variable is unlikely to have
|
Sure, but
Sure, but I wonder how common that is and whether it's too much overhead to require users to use a variable annotation in those cases. I think we should experiment with not providing |
Currently, we use an extra
str
overload when using literals. For example:What's the use case for this? The only thing I can think of is something like this:
But this actually looks like a typing error to me where
mode
should have been annotated withLiteral["r", "w"]
anyway. I would suggest starting to remove these defaults, possibly after the next mypy version is released. primer should warn us if this causes lots of new errors (as I would expect for e.gbuiltins.open()
) and we can then decide on a case-by-case basis to leave the default in for now.Side note: We can't do this for
bool
yet due to python/mypy#6113.The text was updated successfully, but these errors were encountered: