Can't get around "IndexError: list index out of range"
steve at holdenweb.com
Mon Oct 9 09:31:05 CEST 2006
> On Oct 8, 3:05 pm, Steve Holden <s... at holdenweb.com> wrote:
>>No: you are proposing to add features to the sequence interface for
>>which there are few demonstrable use cases.
> If I really wanted to find them, how many instances do you think I
> could find [in the standard lib and community-respected third-party
> libs] of sequence index checking like "if 2 < len(seq)" and / or
> try-excepting like "try: seq ..."? Judging by the fact that there
> isn't any other way to *safely* handle dynamic sequences (esp.
> sequences which grow based on side-effects which may or may not be
> present, depending on the execution path through the code); I'd guess
> the number is alot higher than you seem to think.
Keep right on guessing.
>>Well I certainly didn't find your last one particularly convincing: the
>>attempt to reference a non-existent sequence member is almost always a
> Unless you are interacting with user input, or other anomalous data
> source. And in that case you need to do explicit index checking or wrap
> your code with a try...except; that or you need a convenience function
> or method that implements a non-terminating exception, and you just
> check for the exceptional case, like dictionaries have with get(). I
> find the latter approach to be easier to read and write (see link
> below), as well as understand.
OK, so now we appear to be arguing about whether a feature should go
into Python because *you* find it to be easier to read and write. But I
don't see a groundswell of support from other readers saying "Wow, I've
always wanted to do it like that".
>>I would argue exactly the opposite: the reason why they shouldn't be
>>implemented is because no good reason has been presented why they *should*.
> Pretend like there are no dict.has_key and dict.get methods. Can you
> provide a good reason(s) why they should be implemented? Not necessity
> -- since you can do the same thing more verbosely. Usefulness? --
> Probably; but I think the list methods would also be useful (see
> above). Succinctness ? -- The list methods have the same advantage.
> Anything else?
>  http://mail.python.org/pipermail/python-dev/1999-July/000594.html
Nope. In fact d.has_key(k) is a historical spelling, retained only for
backwards compatibility, of k in dict. As to the d.get(k, default)
method I really don't see a compelling use case despite your
protestations, and I don't seem to be alone. Please feel free to start
> On Oct 8, 3:11 pm, Fredrik Lundh <fred... at pythonware.com> wrote:
>>>Huh? I don't want to treat sequences and mappings as the same thing.
>>>I'm talking about adding two similar convenience methods for sequences
>>>as already exist for mappings.so what makes you think you're the first one who's ever talked about that?
> I looked yesterday and only found a few posts. A couple involved
> Marc-Andre Lemburg, and mxTools, where he has a get() function that
> works for sequences and mappings; that's not what I'm suggesting.
> However, I found one from 1997 where he mentioned a patch to python 1.5
> which added list.get, but I couldn't find the patch or any discussion
> of why it was (presumably) rejected. The only other post I found that
> was relevant was one on the dev-python list (mentioned in the July 1-15
> summery ). And the only thing mentioned there as a reason against it
> is that "It encourages bad coding. You
> shouldn't be searching lists and tuples like that unless you know what
> you're doing." (Whatever that is supposed to mean!).
> Just point me to the discussion where the good reasons (or any at all)
> against my suggestion can be found and I'll be glad to read it. I
> couldn't find it.
The fact that nobody has listed the good reasons why I shouldn't try to
make a computer from mouldy cheese doesn't make this a good idea.
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden
More information about the Python-list