Open plajjan opened 3 days ago
Hmm, so on second consideration, don't we want to have separate method for the get-with-default-value??
With the change as written in this issue and implemented in #1986, we end up having to None-check the result, even when we provide a default value - that seems suboptimal.
Like I feel the whole idea with a default value is that we know we get a non-optional value back. We can never statically enforce the type to be non-optional for a single get method where the default argument is optional, so I guess we need separate methods?
Something like this:
__getitem__(A) -> B
but throws KeyError
if A does not existget(A) -> ?B
returns None
if A does not existgetdef(A, B) -> B
returns B
if A does not existand similar for pop
and popdef
then !?
@sydow @nordlander @ddjoh WDYT?
I agree, get with a default value is not the same as an optional get. One could merge the two by moving to the more elaborate signature
get : [B(D)] => (A, Optional[D]) -> D
but that would require the planned support for unions as well as a lifted restriction in the constraint-solver. For later (perhaps).
The only thing about adding getdef
is that def probably reads as definition to must Python programmers, not default. Maybe getopt
could used instead?
I wouldn't read too much into the name. Can't say I would immediately feel getopt is more intuitive than getdef. I mean, sometimes you just have to learn what something means and not what you might guess from a few characters.
We discussed adding .pop() to dict / Mapping in our weekly meeting.
We said we wanted this:
And these functions should not throw any exceptions - they should return None if the key is not found.