On Fri, 28 Aug 2020 at 09:30, Stephen J. Turnbull <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > > Paul Moore writes: > > > Furthermore, I'd be very, very strongly opposed to having x[i, > > default=d] be a way of supplying a default result if i isn't present > > in *any* subscriptable class, and particularly in dict as an > > equivalent for x.get(i, d). It's redundant, > > True, but not really fair under my assumption that `x[i, default=d]` > becomes the accepted way of doing it generally. dict.get would be a > legacy in that case.
So one of [,default=] and dict.get is redundant. Why make the existing way the redundant one? What's the actual benefit? Particularly as *other* uses of keywords in indexes may well want to allow general keywords (Pandas named columns, for example) so we can't reasonably reserve "default" to mean a default value in the general case. Conversely, having a get method (if it exists) behave like the stdlib dict.get seems a reasonable application of duck typing. > How do you folks feel about list.get and tuple.get (I expect many > folks will think differently about these because tuples are > immutable), and more generally Sequence.get? I'm indifferent to list.get. I've never felt any need for it, and it's easy to implement if someone wants it (as you note in another mail). Making it a list method just means it doesn't work as well as a standalone function (in the sense that it's not going to support other types via duck typing). I see absolutely no point in tuple.get, it seems like the only reasons for it would be over-generalisation, or as a workaround for the fact that methods don't duck-type (x.get(i, default) where you don't know if x is a list or tuple - a get *function* would of course handle this perfectly via duck typing). > > confusing, and unlike any other language I'm familiar with (all > > IMO, if that's not obvious...). > > All this opposition is interesting. For reasons similar to those > expressed by MAL for sequences I rarely use dict.get, let alone want > list.get. To me it usually just feels wrong to be getting something > that might not be there, and then leaving it that way. I use > defaultdict much more than I use dict.get. I use dict.get a lot - as MAL says, not being sure if a particular key is present in a dict is perfectly normal, in contrast to not being sure if an index is valid for a list. Consider that "key in dict" is a language feature, but there's no "index in list" syntax... > Regarding the statement that it's "unlike any other language," I > suspect that's true; the only possible exception would be Lisps, but I > think the argument that they don't have true indexing ends it. Partly > by analogy to Lisp, I think of indexing as an optimized case of > function call (which is how it's implemented in Python! That's just > an amusing observation, not intended seriously.) The square brackets > basically say "you can expect this operation to be O[1], almost always > with small c" for appropriate values of "small". So this syntax > doesn't bother me, given that functions support arbitrary keywords. Lisp is an exception to most things :-) > I guess all this makes me an extremist. Doesn't stop me from liking > the Python you prefer just as well, though. :-) :-) Paul _______________________________________________ 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/XP35WDTDWDNR3JZORLCQKCUUS3QZQ56F/ Code of Conduct: http://python.org/psf/codeofconduct/
