-
-
Notifications
You must be signed in to change notification settings - Fork 1.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
Should the dict.get
overload with default value not be generic?
#9155
Comments
Another pyright user here and +1 on the proposal. I would like it for the first overload (no default argument) as well. I've run into cases where the generic type causes trouble even when I am not passing a default argument. It also seems more consistent. I don't see why it would be correct to do this in the second overload but not the first. I don't remember a case where this generic type helped find a bug. But it has been inconvenient. I'll post back if I find one! |
I think a good middle ground to try first would be to change the |
I like the
I don't think we can just rely on |
When using
dict.get
with a default value, it is expected that the key may not be found. Most of the time it's because we're not dealing with literal types, so we can't ensure that a key is part of the dict. But other times, it's we explicitely use a value that has a type we know won't be in range (often None).See the example below (it is of course minimal and abstracted from a real-world example, but should still show the use):
Currently it has to be written as such (without a cast). Which adds redundancy checks and no type-safety:
What if this definition in dict:
was changed to:
What are your thoughts? Any reason this would be a bad idea? From what I can see there are legit sensible use-cases, it stays type-safe, and allows for more concise code. Or just use a cast and call it a day?
The text was updated successfully, but these errors were encountered: