[Python-ideas] get() method for list and tuples

Paul Moore p.f.moore at gmail.com
Sun Mar 5 09:08:25 EST 2017


On 5 March 2017 at 13:03, Ed Kellett <edk141 at 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.


More information about the Python-ideas mailing list