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

MonkeeSage MonkeeSage at gmail.com
Tue Oct 10 06:41:20 CEST 2006


On Oct 9, 2:31 am, Steve Holden <s... at holdenweb.com> wrote:
> Keep right on guessing.

I hope I'm not offending one whom I consider to be much more skilled
and versed than I am, not only in python, but in programming in
general; but I must say: it seems you are being rather obtuse here. I
think I laid out the principal clearly enough, and I know you have the
mental capacity to extrapolate from the principal to general use cases.
But even so, here is a simple use case from the standard library
(python 2.5 release source):

In Libs/site.py, lines 302-306:

            try:
                for i in range(lineno, lineno + self.MAXLINES):
                    print self.__lines[i]
            except IndexError:
                break

With my proposal, that could be written as:

            for i in range(lineno, lineno + self.MAXLINES):
                if self.__lines.has_index(i):
                    print self.__lines[i]
                else:
                    break

Granted, in this particular case the amount of code is not reduced, but
(and I would hope you'd agree) the control flow is certainly easier to
follow.

> 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".

*Someone* (other than me!) obviously found it nice to have the dict
convenience methods. As for garnishing support, I almost see that as
more of a cultural, rather than pragmatic issue. I.e., if it's not
there already, then it shouldn't be there: "what is is what should be".
Of course, consistently following that naive presumption would totally
stiffle *any* extension to python. However, (I think) I do understand
the psychology of the matter, and don't fault those who cannot see past
what already is (not meaning to implicate you or Fredrick or anyone
else -- the comment is innocent).

> 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
> recruiting support.

As I stated to another poster; I'm not really concerned with
implementation details, only with the presence or absence of
convenience methods. You can write "if k in d" as easily as "if index <
len(seq)". But semantically, they are similar enough, in my (admittedly
lowly) estimation, to desevere similar convenience methods.

> 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.

Heh. True. I didn't mean to imply that I was arguing from the negative.
I was only tring to shift the perspective to include the reasons for
the dict convenience methods. If C is good for A, and A is sufficiently
similar to B, then C is good for B. But if C is just crud, then forget
it all around. ;)


On Oct 9, 12:24 pm, Dennis Lee Bieber <wlfr... at ix.netcom.com> wrote:
>         But how do you handle the case of:
>
> l = []
> i = 10
>
> l[i] = l.get(i, 0) + 1

You don't; you just let the IndexError fall through. Same as a KeyError
for d[k]. My propopsal is in regard to convencience methods, not to
direct access.

Ps. Sorry if this comes through twice, Google is being wierd right now.

Regards,
Jordan




More information about the Python-list mailing list