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

[Steve Holden]

MonkeeSage wrote:
> 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.
> 
I think we'll just have to agree to differ in this repsecrt, as I don't 
see your suggestions for extending the sequence API as particularly 
helpful. The one case you quote doesn't actually use the construct to 
supply a default value, it just terminates a loop early if the sequence 
length is below expectation (unless I've misread the code: that does 
happen).

I don't really think it's a biggy, I just don't see the parallels that 
you do.  Your point about blindness to the need for change is one that 
we do have to be careful of (not that I'm the person to consult about 
what goes into the language anyway). But if you think you've had an 
argument here, try writing a PEP for this and see if you can persuade 
the denizens of python-dev to accept (and implement) it.

regard
  Steve
-- 
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