Why not just show the out-of-range index?

[Russ]

Every Python programmer gets this message occasionally:

IndexError: list index out of range

The message tells you where the error occurred, but it doesn't tell you
what the range and the offending index are. Why does it force you to
determine that information for yourself when it could save you a step
and just tell you? This seems like a "no-brainer" to me. Am I missing
something?

 

[James Stroud]

Every Python programmer gets this message occasionally:

IndexError: list index out of range

The message tells you where the error occurred, but it doesn't tell you
what the range and the offending index are. Why does it force you to
determine that information for yourself when it could save you a step
and just tell you? This seems like a "no-brainer" to me. Am I missing
something?

I think you have a point. I am curious to see how far people are willing
to go to defend this omission. It promises to be entertaining.

James

--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/

 

[John Machin]

I think you have a point. I am curious to see how far people are willing
to go to defend this omission. It promises to be entertaining.

Add "Syntax Error: invalid syntax" to the list ...

 

[Robert Kern]

I think you have a point. I am curious to see how far people are willing
to go to defend this omission. It promises to be entertaining.

I'm not sure that anybody is going to defend it as a deliberate omission.
Rather, they (like I) will encourage to OP to submit a patch that fixes the problem.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Russ]

Rather, they (like I) will encourage to OP to submit a patch that fixes the problem.

Now, that would be rather silly. I would have to familiarize myself
with the code for the Python interpreter, then send a patch to the
maintainers (and hope they notice it in their inboxes), while the
maintainers themselves could probably "fix" the problem in two minutes
flat. No thanks!

My suggestion is trivial to implement and would benefit every Python
programmer (even if only slightly), so I don't think it is too much to
ask for.

 

[mensanator]

Add "Syntax Error: invalid syntax" to the list ...

But at least if you're using IDLE, the point of syntax error
is highlighted.

When I was a programmer, I thought as a programmer,
I spake as a programmer and I understood as a programmer.
But when I became a User, I put away such childish things.

 

[John Machin]

But at least if you're using IDLE, the point of syntax error
is highlighted.

Same when using the interactive interpreter, the point of syntax error
is highlighted with a caret. However the highlighting of WHERE is
useless to people who don't have a clue WHAT the error is, and it needs
a forensic guru to suss it out as for example Peter Otten did, only
yesterday:
"""
Are you perhaps mixing tabs and spaces?

.... print "hello" # four spaces before 'print'
.... return 42 # one tab before 'return'
File "<stdin>", line 3
return 42
^
SyntaxError: invalid syntax
"""

 

[Robert Kern]

Now, that would be rather silly. I would have to familiarize myself
with the code for the Python interpreter, then send a patch to the
maintainers (and hope they notice it in their inboxes), while the
maintainers themselves could probably "fix" the problem in two minutes
flat. No thanks!

And I believe that answers your original question.

PS: begging for a fix on comp.lang.python is even less likely to get the
developer's attention than posting a patch. They listen to patch submissions
much more than comp.lang.python. At the very least, you should submit a bug
report even if you don't want to take the opportunity to learn how to fix it
yourself.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[mensanator]

Same when using the interactive interpreter, the point of syntax error
is highlighted with a caret. However the highlighting of WHERE is
useless to people who don't have a clue WHAT the error is, and it needs
a forensic guru to suss it out as for example Peter Otten did, only
yesterday:
"""
Are you perhaps mixing tabs and spaces?


... print "hello" # four spaces before 'print'
... return 42 # one tab before 'return'
File "<stdin>", line 3
return 42
^
SyntaxError: invalid syntax
"""

Well, more information would be better, but at least it's
not as bad as Windows:

Application xxx could not be started because a
required file could not be found. I know the name
of the file but I am not going to tell you what
it is.

 

[Dennis Lee Bieber]

Application xxx could not be started because a
required file could not be found. I know the name
of the file but I am not going to tell you what
it is.

Try this one:

The document name or path is not valid. Try these suggestions.
* Check the file permissions for the document or drive.
* Use the File Open dialog box to locate the document. (E:\djrn.doc)

This is from Word, using a file generated by a genealogy program. It
works for a file with a single start individual, but fails on the one
with a "chapter" (the generator program isn't smart enough to do more
than put in a new-page code) for each end-of-line ancestor. The latter
is an 11MB file. Furthermore, I can send the file to Wordpad and get the
raw text (though Wordpad seems unable to detect the Word format codes
too). Generate as an RTF (5MB) and Word can load it, saving it to an 8MB
file which it can also reload.
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Gary Herron]

Now, that would be rather silly. I would have to familiarize myself
with the code for the Python interpreter, then send a patch to the
maintainers (and hope they notice it in their inboxes), while the
maintainers themselves could probably "fix" the problem in two minutes
flat. No thanks!

My suggestion is trivial to implement and would benefit every Python
programmer (even if only slightly), so I don't think it is too much to
ask for.

But with that argument you just perpetuate the problem. It is the way it
is because nobody has cared enough to make it different. That error
message has certainly never bothered me enough to wish for something
different.

You may be able to prompt someone into changing it, but if we've gone
this long without caring to fix it, then I'd not hold out much hope for
that. Python and the whole open source movement is a volunteer effort by
people who care enough to contribute. Your contributions would be
welcome, but your complaints are likely to be ignored.

Gary Herron

 

[Russ]

And I have some laundry that I would like you to do for me. Let me know
when a convenient time for you to pick it up would be.

What that has to do with this thread escapes me, but since you
apparently have nothing better to do than track down information that
should have been provided to you, it's no wonder you don't have enough
time to do your own laundry.

When you call information to get a phone number, do you first ask if
they have the number, then call back a second time to get it if the
answer is yes?

If a policemen gives you a speeding ticket, do you expect him to tell
you how fast he thinks you were going, or are you content to wait for
the court date?

Get your mother to do your laundry -- after she dresses you in the
morning.

 

[John Machin]

And I have some laundry that I would like you to do for me. Let me know
when a convenient time for you to pick it up would be.

Jean-Paul

Perhaps a better analogy is that the OP has observed (correctly IMHO)
that the robes of *all* Pythonistas, including those not yet born and
those not yet converted from heathen languages, could be whiter than
what they are. There are others whose capability to implement an
enhancement is likely to be much greater than his.

IOW, apart from being somewhat impolite, he may:
* not be able to write C
* not understand that apart from listobject.c, he might have to patch
(OTTOMH) stringobject.c, tupleobject.c, arraymodule.c and who knows
what else [see below]
* not come up with a good message

Would the following be acceptable, BTW?

| >>> [4, 5, 6][10]
| IndexError: list index 10 out of range(3)
| >>> [4, 5, 6][-4]
| IndexError: list index -4 out of range(3)

or would something like
... out of range; len is 3
be better?

Footnote: Based on 2.4.3 source, quite a few files, many with multiple
lines to patch:

C:\Python_source\Python-2.4.3\Objects>grep -n "index out of range" *.c
File bufferobject.c:
406 PyErr_SetString(PyExc_IndexError, "buffer index
out of range");
450 "buffer assignment index out of
range");
File listobject.c:
144 "list index out of range");
165 "list assignment index out of
range");
389 "list index out of range");
693 "list assignment index out of
range");
881 PyErr_SetString(PyExc_IndexError, "pop index
out of range");
File rangeobject.c:
143 "xrange object index out of
range");
File stringobject.c:
1041 PyErr_SetString(PyExc_IndexError, "string index
out of range");
File structseq.c:
62 PyErr_SetString(PyExc_IndexError, "tuple index
out of range");
File tupleobject.c:
104 PyErr_SetString(PyExc_IndexError, "tuple index
out of range");
123 "tuple assignment index out of
range");
310 PyErr_SetString(PyExc_IndexError, "tuple index
out of range");
File unicodeobject.c:
5241 PyErr_SetString(PyExc_IndexError, "string index out of
range");

C:\Python_source\Python-2.4.3\Modules>grep -n "index out of range" *.c
File arraymodule.c:
599 PyErr_SetString(PyExc_IndexError, "array index
out of range");
767 "array assignment index out of
range");
997 PyErr_SetString(PyExc_IndexError, "pop index
out of range");
File collectionsmodule.c:
399 "deque index out of range");
461 "deque index out of range");
File mmapmodule.c:
648 PyErr_SetString(PyExc_IndexError, "mmap index
out of range");
736 PyErr_SetString(PyExc_IndexError, "mmap index
out of range");
File regexmodule.c:
181 PyErr_SetString(RegexError, "group() index out
of range");
File _heapqmodule.c:
19 PyErr_SetString(PyExc_IndexError, "index out of
range");
58 PyErr_SetString(PyExc_IndexError, "index out of
range");
136 PyErr_SetString(PyExc_IndexError, "index out of
range");
173 PyErr_SetString(PyExc_IndexError, "index out of
range");
310 PyErr_SetString(PyExc_IndexError, "index out of
range");
349 PyErr_SetString(PyExc_IndexError, "index out of
range");

Cheers,
John

 

[Russ]

Perhaps a better analogy is that the OP has observed (correctly IMHO)
that the robes of *all* Pythonistas, including those not yet born and
those not yet converted from heathen languages, could be whiter than
what they are. There are others whose capability to implement an
enhancement is likely to be much greater than his.

I love Python, but every time I get an out-of-range error message, I
wonder why it didn't just tell me what the out-of-range index was and
what the allowable range was. Certainly that information must be
available to the exception handler, or how would it know that it is out
of range? And no, it's not a big deal, maybe it's even trivial, but
after about the 100th time I finally decided to suggest that it be
fixed. I started with comp.lang.python because I had no idea whether
this issue had been dealt with already, but I am certainly willing to
file a feature request if necessary.

Would the following be acceptable, BTW?

| >>> [4, 5, 6][10]
| IndexError: list index 10 out of range(3)
| >>> [4, 5, 6][-4]
| IndexError: list index -4 out of range(3)

That seems fine to me.

Footnote: Based on 2.4.3 source, quite a few files, many with multiple
lines to patch:

Holy cow! I can't believe that many changes would be necessary unless
the IndexError exception is scattered all over the place. I would hope
that one well-placed change could fix the bulk of cases.

Oh, and thanks for bringing your attention to this matter. This is one
of those little issues that comes up so often that I think fixing it
could make a significant difference in the overall efficiency of Python
programming.

 

[Dennis Lee Bieber]

Holy cow! I can't believe that many changes would be necessary unless
the IndexError exception is scattered all over the place. I would hope
that one well-placed change could fix the bulk of cases.

If you notice, those were the calls that /raise/ IndexError... So to
format with additional information about what the value was, vs what the
range is, has to be done at those points -- that's where the
determination took place). Once it has been raised, it is too late to
retrieve the information as to what object/value was involved.

Oh, and thanks for bringing your attention to this matter. This is one
of those little issues that comes up so often that I think fixing it
could make a significant difference in the overall efficiency of Python
programming.

OTOH: IndexError is something I seldom see -- most Python statements
are intelligent enough to not need ad hoc indexing. About the only type
that I've seen is just an, almost obvious, off-by-one problem...

for i in xrange(len(a)):
a = a + a[i+1]

in which knowing the discrete values isn't that significant (to me, at
least)

It doesn't occur in things like

for itm in a:
...
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Bill Maxwell]

And I have some laundry that I would like you to do for me. Let me know
when a convenient time for you to pick it up would be.

Jean-Paul

Are you saying that you place such low value on feedback from Python
users that you don't even want them to try and ask questions that might
help to improve the language?

In other words, if I'm not skilled or knowledgeable enough to improve
something myself, I shouldn't even mention it?


Bill

 

[Russ]

OTOH: IndexError is something I seldom see -- most Python statements
are intelligent enough to not need ad hoc indexing. About the only type
that I've seen is just an, almost obvious, off-by-one problem...

for i in xrange(len(a)):
a = a + a[i+1]

in which knowing the discrete values isn't that significant (to me, at
least)

It doesn't occur in things like

for itm in a:

I agree that implicit indexing (your latter construct) is preferable to
explicit indexing if the index is not needed for any other purpose. But
sometimes the index itself is needed for some computation. And
sometimes a list is "randomly" accessed without a loop at all.

 

[Fredrik Lundh]

Holy cow! I can't believe that many changes would be necessary unless
the IndexError exception is scattered all over the place. I would hope
that one well-placed change could fix the bulk of cases.

when you write x, the interpreter makes no assumptions about x and i
and len(x); it just calls the corresponding method (__getitem__), either
directly, or via a C-level internal slot.

there's no way to generate the error message you want in a single place
without changing the semantics of x.

</F>

 

[Robert Kern]

Are you saying that you place such low value on feedback from Python
users that you don't even want them to try and ask questions that might
help to improve the language?

In other words, if I'm not skilled or knowledgeable enough to improve
something myself, I shouldn't even mention it?

No one is castigating the OP for bringing up the issue. His suggestion that his
time is worth more than that of anyone else, though, is drawing some ire.
Fortunately, he seems to have backed off this position and seems amenable to
doing something more productive than posting here.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Russ]

Holy cow! I can't believe that many changes would be necessary unless
the IndexError exception is scattered all over the place. I would hope
that one well-placed change could fix the bulk of cases.

when you write x, the interpreter makes no assumptions about x and i
and len(x); it just calls the corresponding method (__getitem__), either
directly, or via a C-level internal slot.

there's no way to generate the error message you want in a single place
without changing the semantics of x.

Then how about just changing __getitem__ for the built-in list type.
Wouldn't that take care of the vast majority of cases? Let anyone who
writes their own __getitem__ handle it themselves if they wish. I'm
just asking. I don't claim to know anything about the internals of the
Python interpreter.