On Thu, Aug 27, 2020 at 11:49:22PM +0900, Stephen J. Turnbull wrote:
> Alex Hall writes:
>
> > OK, I'll try again. Do people want collections to get a standard 'default'
> > for `__getitem__`?
>
> I don't know.
I'm pretty sure that Guido said that he doesn't want the builtin dict
and list types to get keyword arguments. That might change in the
future, but I'm assuming that if keyword subscripts are supported, they
will be added for the sake of projects like pandas, numpy, and xarray,
not because there are plans to change the builtins.
> > I don't want mappings to grow a second way to do the same thing,
>
> They're going to get one, is my reading of the "named indicies"
> thread. That is, it looks to me very likely that index notation
> (`x[i]`) is going to support keyword arguments (`x[i, k=v]`). If so,
> that's going to be a natural way to support a `default` argument.
It might have been the natural way to do it in 1991, if keyword
subscripts existed back then. But they didn't, so now, in 2020, the
natural way to do this in a dict is with the get method.
That's not going to go away.
> I
> imagine some people will choose it because they like it, and if there
> are enough people who do there will be pressure for it to be TOOWTDI.
*shrug*
If keyword subscripts are allowed;
and if they become really popular outside of pandas etc;
and people start using the `mapping[key, default=0]` idiom in third
party mappings;
and it becomes a defacto standard for mappings outside of the stdlib;
and people want builtin dict to support the same idiom;
then there might be some pressure on the core devs to add it to dict.
But until such time, I wouldn't expect dicts to change.
So I think this issue is a distraction.
Unless the senior core devs like Guido, Brett, Nick, Serhiy, Raymond,
etc (my apologies to anyone I missed) say that they're intending to add
keywords to dict subscripting, I wouldn't expect the get method to
become obsolete.
I think the problem with list.get is that there are already a plethora
of ways to do it:
- Look Before You Leap:
# assumes index is non-negative
default if len(L) < index else L[index]
- Easier to Ask Forgiveness than Permission:
try:
L[index]
except IndexError:
default
- Slicing:
# likewise assumes index is non-negative
(L[index:index+1] or [default])[0]
- any of which can be put into a helper function
get(L, index, default)
(Maybe add this to the operator module?)
So unless this happens to scratch somebody's personal itch, I think
you're going to run up against the problem that while this is useful,
it's maybe not useful enough to bother.
Personally, I ever so slightly lean towards the "if it already existed,
I'd definitely use it, but I don't care enough to fight for it"
position. I'm running out of energy to care about things I actually care
about, and this is so far down the list that I'm honestly not sure why
I'm even writing this :-)
Probably as an avoidance tactic to avoid doing other more important
things *wink*
--
Steve
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/PO3344SEOOHGGZHBM2SHB3KIWOMBRPMD/
Code of Conduct: http://python.org/psf/codeofconduct/
