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

[MonkeeSage]

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