On 5 March 2017 at 13:03, Ed Kellett <edk...@gmail.com> wrote: > > No. I'm asking: if list.get did exist, are there any cases (compatibility > with old versions aside) where list.get's semantics would be applicable, but > one of the alternatives would be the better choice?
Self-evidently no. But what does that prove? That we should implement list.get? You could use the dientical argument for *anything*. There needs to be another reason for implementing it. >> "writing a helper function" is a generally >> useful idiom that works for many, many things, but list.get only >> solves a single problem and every other such problem would need its >> own separate language change. > > Custom helper functions can obviously accomplish anything in any language. > If we had to choose between def: and list.get, I'd obviously opt for the > former. > >> The disadvantage that you have to write >> the helper is trivial, because it's only a few lines of simple code: > > I don't think the size of a helper function is relevant to how much of a > disadvantage it is. Most built-in list methods are trivial to implement in > Python, but I'm glad not to have to. But you have yet to explain why you'd be glad not to write a helper for list.get, in any terms that don't simply boil down to "someone else did the work for me". I think we're going to have to just disagree. You won't convince me it's worth adding list.get unless you can demonstrate some *existing* costs that would be removed by adding list.get, and showing that they are greater than the costs of adding list.get (search this list if you don't know what those costs are - I'm not going to repeat them again, but they are *not* trivial). And I don't seem to be able to convince you that writing a helper function is a reasonable approach. Paul. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
