Can't get around "IndexError: list index out of range"

[Steven D'Aprano]

On Sat, 07 Oct 2006 18:06:47 -0700, MonkeeSage wrote:

> On Oct 7, 7:59 pm, Steven D'Aprano
> <s... at REMOVE.THIS.cybersource.com.au> wrote:
>> Because they aren't needed often, and when they are, they are easy to
>> implement?
> 
> More often and easier to implement than dict.has_key / get?

No, *less* often. That's the point -- it is fairly common for people to
want dictionary lookup to return a default value, but quite rare for them
to want sequence lookup to return a default value. A sequence with a
default value would be, in some sense, equivalent to an infinite list:

[A, B, ... , Z, default, default, default, ... ]

where the A...Z are actual values. (Obviously you don't actually have an
infinite list.) 

I can't think of any practical use for such a thing; the only thing that
comes close is in some Cellular Automata it is sometimes useful to imagine
cells out of range to be always in some default state. But generally
speaking, you don't implement Cellular Automata with lists.



>> It is hard to see where list.get(index, default) would be useful, since
>> accessing an index out of range of a list is generally an error, unlike
>> accessing a missing key.
> 
> Uh, no. KeyError.

dict.get() doesn't raise KeyError. That's the whole point of get(), it
returns a default value instead of raising KeyError.


>> Not every piece of functionality needs to be a built-in.
> 
> Agreed. but why implement a certain functionality in one place but leave
> it out of another?

Because implementation requires time and effort. It makes the regression
tests more complicated and bloats the code base. If the feature doesn't
scratch anybody's itch, if there isn't a clear use for it, it won't be
implemented. If you don't care enough to even make a formal feature
request, let alone a PEP, then why should people who care even less
actually write the code?


-- 
Steven.