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]

Russ wrote:

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]

James Stroud wrote:

Russ wrote:

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.

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

[Robert Kern]

James Stroud wrote:

Russ wrote:

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

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]

John Machin wrote:

James Stroud wrote:

Russ wrote:

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.

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]

me********@aol.com wrote:

John Machin wrote:

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

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?

>>def f():

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

[Robert Kern]

Russ wrote:

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

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]

John Machin wrote:

me********@aol.com wrote:

John Machin wrote:

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

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?

>def f():

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

[Russ]

Jean-Paul Calderone wrote:

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.

[Gary Herron]

Russ wrote:

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

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

[John Machin]

Jean-Paul Calderone wrote:

On 3 Dec 2006 17:23:49 -0800, Russ <uy*******@sneakemail.comwrote:

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!

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]

John Machin wrote:

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.

[Bill Maxwell]

On Sun, 3 Dec 2006 23:31:56 -0500, Jean-Paul Calderone
<ex*****@divmod.comwrote:

>On 3 Dec 2006 17:23:49 -0800, Russ <uy*******@sneakemail.comwrote:

>>

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

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]

Dennis Lee Bieber wrote:

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[i] = a[i] + 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]

Russ wrote:

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[i], 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[i].

</F>

[Robert Kern]

Bill Maxwell wrote:

On Sun, 3 Dec 2006 23:31:56 -0500, Jean-Paul Calderone
<ex*****@divmod.comwrote:

>On 3 Dec 2006 17:23:49 -0800, Russ <uy*******@sneakemail.comwrote:

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

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?

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]

Fredrik Lundh wrote:

Russ wrote:

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[i], 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[i].

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.

[Russ]

Robert Kern wrote:

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.

I'm afraid that any such "suggestion" is purely in your own
imagination. My time? Do you think I am the only one who has
IndexErrors?

Fortunately, he seems to have backed off this position and seems amenable to
doing something more productive than posting here.

I made a simple suggestion to enhance the convenience and productivity
of Python, and I was attacked for even discussing it rather than
immediately doing it myself. WTF?

[Fredrik Lundh]

Russ wrote:

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

I'm afraid that any such "suggestion" is purely in your own
imagination.

"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 a couple of other posts with a similar tone. open source developers
tend to ignore people who use the "you're just a bunch of code monkeys"
intimidation approach, especially when combined with an undertone of
"what I'm proposing should be easy, and if it isn't, that's because
you're incompetent". claiming to talk for everyone else doesn't really
help, either.

I suggest doing what you should have done from the start; go to the
feature request tracker:

http://sourceforge.net/tracker/?grou...70&atid=355470

and click "suggest new".

</F>

[Russ]

Fredrik Lundh wrote:

Russ wrote:

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.

I'm afraid that any such "suggestion" is purely in your own
imagination.

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

That is a perfectly reasonable statement. Forgive me if I
underestimated the difficulty of implementing the feature I suggested,
but I still don't think it would be difficult for the code maintainers
to implement. They are obviously familiar with the code, but I'm not!

and a couple of other posts with a similar tone. open source developers
tend to ignore people who use the "you're just a bunch of code monkeys"
intimidation approach, especially when combined with an undertone of
"what I'm proposing should be easy, and if it isn't, that's because
you're incompetent". claiming to talk for everyone else doesn't really
help, either.

Boy, some of you guys seem to have a very low self esteem, reading
insults where none exist. "Just a bunch of code monkeys"?!! Where in
the friggin' world did I say anything remotely resembling that? I
happen to be a proud "code monkey" myself, for crying out loud! And
excuuuuuuuuuuuuuse me for suggesting a minor new feature to enhance the
productivity of Python without implementing it myself! Geez!

[Robert Kern]

Russ wrote:

And
excuuuuuuuuuuuuuse me for suggesting a minor new feature to enhance the
productivity of Python without implementing it myself! Geez!

Like I said, no one is castigating you for making the request. It's been your
attitude afterwards that is the problem. You've been pointed to the productive
things you can do to resolve the issue that you have:

1. Submit a bug report.
2. Submit a patch.

Nothing is going to happen until you do one of these two things. Being more rude
(and yes, you are being incredibly rude and insulting) won't move things along.

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

[Fredrik Lundh]

Russ wrote:

Boy, some of you guys seem to have a very low self esteem

yeah, of course. it's always someone else's fault. now, can you please
go to the feature request tracker:

http://sourceforge.net/tracker/?grou...70&atid=355470

and follow the instructions on that page?

</F>

[Russ]

Robert Kern wrote:

Nothing is going to happen until you do one of these two things. Being more rude
(and yes, you are being incredibly rude and insulting) won't move things along.

I re-read the thread, and I don't see anywhere where I was rude except
in reply to rudeness by others. Sorry, but I haven't mastered the "turn
the other cheek" thing yet.

My suggestion that it would be much easier for the Python maintainers
than for me to implement the requested feature is just basic common
sense. I would have to spend many hours or days just to familiarize
myself with the code, but they are obviously already very familiar with
it. And they would probably have to spend nearly as much time checking
my patch as they would writing it themselves anyway.

By the way, your parenthical assertion that I am "being incredibly rude
and insulting" is itself an unwarranted and devious insult, and I will
not let you get away with it without being called on it. But I'm
willing to forget about it and move on, and I'll assume you are too.

[Robert Kern]

Russ wrote:

Robert Kern wrote:

>Nothing is going to happen until you do one of these two things. Being more rude
(and yes, you are being incredibly rude and insulting) won't move things along.

I re-read the thread, and I don't see anywhere where I was rude except
in reply to rudeness by others. Sorry, but I haven't mastered the "turn
the other cheek" thing yet.

Learn quickly if you are going to keep asking for other people's help.

My suggestion that it would be much easier for the Python maintainers
than for me to implement the requested feature is just basic common
sense. I would have to spend many hours or days just to familiarize
myself with the code, but they are obviously already very familiar with
it. And they would probably have to spend nearly as much time checking
my patch as they would writing it themselves anyway.

You're still missing the other side of the balance: how much the person wants
the feature. I simply don't care enough about the issue to put in the effort
that it would take me. You don't care enough, either, to put in the effort that
it would take you. That's fine. That's your judgment to make. What's
disrespectful is your expectation that you can make that judgment call for other
people. Just because it might take me less time to do it doesn't mean that I am
obliged to want it as much as you do.

By the way, your parenthical assertion that I am "being incredibly rude
and insulting" is itself an unwarranted and devious insult, and I will
not let you get away with it without being called on it.

As you wish. Insults are in the ear of the listener, not the speaker. With that
rule in mind, however, what I said is a simple statement of fact. If the
statement of facts insults you, I'm sorry. You are going to have a very
difficult time here.

You're also missing that *I'm trying to help you*. The way that you have been
acting, regardless of whether you think it is rude or not, will not convince
anyone to solve your problem.

In short, you've asked for a feature in the hope that someone will think it
important enough to do it themselves. No one who has read the thread does. At
least, not in the time frame since you've posted. That may change; in which
case, you should submit the bug report so that the core developers who didn't
read this thread (i.e. nearly all of them) will see it. Maybe they will be in a
small-feature-implementing mood and will want to implement it. If you don't
submit the bug report, odds are everyone will forget all about it.

Or you can take this as a learning opportunity, and make the fix yourself. Then
the next time you run into something like this (and I imagine that you will),
you can take the two minutes to fix it.

But I'm
willing to forget about it and move on, and I'll assume you are too.

Submit the bug report, and I will.

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

[Carsten Haese]

On Mon, 2006-12-04 at 01:04 -0800, Russ wrote:

Robert Kern wrote:

Nothing is going to happen until you do one of these two things. Being more rude
(and yes, you are being incredibly rude and insulting) won't move things along.

I re-read the thread, and I don't see anywhere where I was rude

Please allow me to break it down for you:

Your first reply on this thread, or second message, said:

"""
Now, that [submitting a patch that fixes the problem] 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.
"""

You may not have meant this to be rude, but it does come off as rude and
arrogant, and I'll explain to you why: In your first post you stated
that the feature seems like a no-brainer to you. That implies to the
reader that you might have the necessary skill to implement the feature
yourself, hence Robert's suggestion to submit a patch was, in the
context you gave yourself, neither unreasonable nor silly. I can see how
your calling a reasonable suggestion by a valuable community member
"silly" would be construed as rude and arrogant.

Hope this helps,

Carsten.

[Paul McGuire]

I think your biggest initial recoil to the response you got was in the
request that you submit a patch. You thought, "Geez, I just want one
friggin' error message changed, and they want me to learn the whole Python
development environment." Given your newbiness with Python, probably a
better response to you would be, "Submit this as a feature request at the SF
tracker page. If you really feel ambitious, put together a patch to go with
it, it will increase the likelihood of getting accepted about 50X."

A couple of other notes:
- The core developers do post here, but the real core Python development
discussions go on on the pydev mailing list.
- Please recognize that you did get at least one response from John Machin,
who scanned the code for this simple error message, and found that the
impact was actually in about a dozen places (not uncommon when peeling away
at the onion of source code, you've probably seen this yourself). This gave
all of us a better appreciation of the size of the effort required for what
initially seemed like a 30-second job. (BTW, there are *never* any 30-second
jobs, especially in a package the size of Python.)

So let me echo the effbot and ask that you submit this at the feature
request tracker page on SF - I think you've spent more time in posting to
this thread than it would have taken to submit this request. If you don't
want to learn the Python dev environment, that's fine, you might consider
composing a pydev mailing list submission making your case on the merits of
implementing some user-friendliness features, such as more explanatory error
messages. But the plain truth is, patches speak louder than words, on pydev
even moreso than c.l.py.

-- Paul

[rurpy]

Carsten Haese wrote:

On Mon, 2006-12-04 at 01:04 -0800, Russ wrote:

Robert Kern wrote:

Nothing is going to happen until you do one of these two things. Being more rude
(and yes, you are being incredibly rude and insulting) won't move things along.

I re-read the thread, and I don't see anywhere where I was rude

Please allow me to break it down for you:

Your first reply on this thread, or second message, said:

"""
Now, that [submitting a patch that fixes the problem] 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.
"""

You may not have meant this to be rude, but it does come off as rude and
arrogant, and I'll explain to you why: In your first post you stated
that the feature seems like a no-brainer to you. That implies to the
reader that you might have the necessary skill to implement the feature
yourself, hence Robert's suggestion to submit a patch was, in the
context you gave yourself, neither unreasonable nor silly. I can see how
your calling a reasonable suggestion by a valuable community member
"silly" would be construed as rude and arrogant.

Thanks for explaining why the OP was rude. Having been
reading and listening to english for only a few decades
probably, I am sure the OP (and me too!) appreciates your
explanation of rudeness. It was really hard for me to see it
until you explained it so well. The great thing about c.l.p. is
how much one learns about non-Python things here.
(oops, I hope I wasn't rude by saying there were non-Python
things? I didn't mean to diminish Python in any way.)

Russ,
Please rememer that learning Python is not done overnight --
there are many different levels of knowlage and only the
most elite Pythonists have reached True Understanding.

Since there are many things you don't understand, it is
best you (and me too!) do not make suggrestions publically.
Infidels could read them and inplying that Python is not
perfect and you will undermine the spritual growth of
many other newbies.. Such dangerous sugggestions
should be made privately at the alter of Sourceforge, with
a lot of deep self-reflection and piety.

Until you achive greater understanding it is best if in public
you make sure that you write with the following in mind:
Python is perfect
Perl sucks
Static typing sucks
Python is faster than C
Quoting frequently from the holy Zen of Python is also
helpful. Please remember that many regulars here are
members of the holy priesthood because they have spent
many years studying the Python scriptures. Be as circumspect
in addressing them as you would be a medival knight or
Japanese samurai. Only by following their guidance with
complete devoutness and faith will you be able to achive
the deepest level of Python appreciation.

Hope this helps.

[Carsten Haese]

On Mon, 2006-12-04 at 08:49 -0800, ru***@yahoo.com wrote:

Carsten Haese wrote:

On Mon, 2006-12-04 at 01:04 -0800, Russ wrote:

Robert Kern wrote:
>
Nothing is going to happen until you do one of these two things. Being more rude
(and yes, you are being incredibly rude and insulting) won't move things along.
>
I re-read the thread, and I don't see anywhere where I was rude

Please allow me to break it down for you:

Your first reply on this thread, or second message, said:

"""
Now, that [submitting a patch that fixes the problem] 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.
"""

You may not have meant this to be rude, but it does come off as rude and
arrogant, and I'll explain to you why: In your first post you stated
that the feature seems like a no-brainer to you. That implies to the
reader that you might have the necessary skill to implement the feature
yourself, hence Robert's suggestion to submit a patch was, in the
context you gave yourself, neither unreasonable nor silly. I can see how
your calling a reasonable suggestion by a valuable community member
"silly" would be construed as rude and arrogant.

Thanks for explaining why the OP was rude. Having been
reading and listening to english for only a few decades
probably, I am sure the OP (and me too!) appreciates your
explanation of rudeness. It was really hard for me to see it
until you explained it so well. The great thing about c.l.p. is
how much one learns about non-Python things here.
(oops, I hope I wasn't rude by saying there were non-Python
things? I didn't mean to diminish Python in any way.)

Russ,
Please rememer that learning Python is not done overnight --
there are many different levels of knowlage and only the
most elite Pythonists have reached True Understanding.

Since there are many things you don't understand, it is
best you (and me too!) do not make suggrestions publically.
Infidels could read them and inplying that Python is not
perfect and you will undermine the spritual growth of
many other newbies.. Such dangerous sugggestions
should be made privately at the alter of Sourceforge, with
a lot of deep self-reflection and piety.

Until you achive greater understanding it is best if in public
you make sure that you write with the following in mind:
Python is perfect
Perl sucks
Static typing sucks
Python is faster than C
Quoting frequently from the holy Zen of Python is also
helpful. Please remember that many regulars here are
members of the holy priesthood because they have spent
many years studying the Python scriptures. Be as circumspect
in addressing them as you would be a medival knight or
Japanese samurai. Only by following their guidance with
complete devoutness and faith will you be able to achive
the deepest level of Python appreciation.

Hope this helps.

My sarcasm meter just exploded.

-Carsten

[Martin v. Löwis]

Russ schrieb:

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?

Yes, that is true. The information is readily available.

It's not true that it is "trivial" to fix, though: for every fix, there
ought to be a new test case also, and you have to run the test suite.
Depending on how fast a developer is, it may take between 30min and
1hour to get a fix implemented (for the list case alone, not counting
all the other sequences).

Even though I could fix it, I don't feel tempted to do so: I never had
this problem; in most cases of IndexError, it was very clear what the
problem was so I didn't need the additional information.

Regards,
Martin

[Russ]

Carsten Haese wrote:

You may not have meant this to be rude, but it does come off as rude and
arrogant, and I'll explain to you why: In your first post you stated
that the feature seems like a no-brainer to you. That implies to the
reader that you might have the necessary skill to implement the feature
yourself, hence Robert's suggestion to submit a patch was, in the
context you gave yourself, neither unreasonable nor silly. I can see how
your calling a reasonable suggestion by a valuable community member
"silly" would be construed as rude and arrogant.

Hope this helps,

OK, fair enough. I shouldn't have called his suggestion "silly." When I
replied to him I honestly thought it was, but in retrospect I now see
that it wasn't. My mistake.

By the way, I consider myself a pretty good Python programmer, but I
haven't used C in many years, and I have no desire to ever use it -- or
even see it -- again. That's one of the reasons I use Python in the
first place. (I am fortunate enough to get to choose the language I
use.) I think it's unfortunate that Python is written in C, but I won't
get into that now. (And yes, I am aware of Jython, but I don't care
much for Java either.)

[Martin v. Löwis]

Russ schrieb:

My suggestion that it would be much easier for the Python maintainers
than for me to implement the requested feature is just basic common
sense. I would have to spend many hours or days just to familiarize
myself with the code, but they are obviously already very familiar with
it.

That is all true. However, you seem to be implying that therefore, it
is the Python maintainers who ought to fix this. That implication is
faulty. Not everything that somebody could do better than you should
be done by that other person - some things you have to do yourself
if you want to see them done.

All Python contributors (including the maintainers) are volunteers,
none of us is paid. Volunteers tend to do what they have fun doing
or what scratches their own itches. This is just how free software
works.

And they would probably have to spend nearly as much time checking
my patch as they would writing it themselves anyway.

No: if you already have done the testing, and provided test cases
to test it, this is fairly easy to review.

Regards,
Martin

[Martin v. Löwis]

ru***@yahoo.com schrieb:

Thanks for explaining why the OP was rude. Having been
reading and listening to english for only a few decades
probably, I am sure the OP (and me too!) appreciates your
explanation of rudeness

You mean, you don't feel insulted if somebody calls you
silly?

Regards,
Martin

[OKB (not okblacke)]

Russ wrote:

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 the same could be said of virtually all exceptions. What I
think would be ideal is that whenever an exception is raised, the
traceback tells you:

1) What the exception is
2) The names of the variables involved in the offending expression
(or their character position in the line)
3) The values of those variables

This would be especially useful in cases where you have some long
expression and you get a "cannot concatenate str and list" or whatever.
The irritating thing about this as it is is that you cannot tell which
variables in the expression are causing the problem.

I realize that in some cases the offending expression may not be a
single variable, but I am curious whether it would be possible for
something like this:

"1" + "2" + "3" + "4" + 5 + "6"

To point to the actual addition that raises the exception (somewhat
like it does for a syntax error), instead of just saying "there is an
error somewhere in this line".

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

[rurpy]

Martin v. Löwis wrote:

ru***@yahoo.com schrieb:

Thanks for explaining why the OP was rude. Having been
reading and listening to english for only a few decades
probably, I am sure the OP (and me too!) appreciates your
explanation of rudeness

You mean, you don't feel insulted if somebody calls you
silly?

This is a hypothetical question, right? Since the OP
didn't call you or anyone else silly.

O.P. wrote:

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,

Seems to me he called the suggestion (made without any
knowlage of the OP's abilities regarding C and Python's
internals) that he summit a patch, silly.

I aggree.

His response was well within the bounds of normal
usenet discourse.

[BJörn Lindqvist]

On 12/4/06, "Martin v. Löwis" <ma****@v.loewis.dewrote:

Russ schrieb:

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?

Yes, that is true. The information is readily available.

It's not true that it is "trivial" to fix, though: for every fix, there
ought to be a new test case also, and you have to run the test suite.
Depending on how fast a developer is, it may take between 30min and
1hour to get a fix implemented (for the list case alone, not counting
all the other sequences).

Maybe it is not as trivial as the OP thought, but it can't be that
hard. It could be implemented as a utility function that does the
index checking:

bool
PyObject_IsIndexOutOfBounds(PyObject *o, const char *ob_name, int i)
{
if (i < 0 || i >= o->ob_size)
{
char buf[256];
const char fmt[] = "%s index %d not in range(%d)"
snprintf(buf, fmt, ob_name, i, o->ob_size);
PyErr_SetString(PyExc_IndexError, buf);
return true;
}
return false;
}

Then replace all code like:

if (i < 0 || i >= a->ob_size) {
PyErr_SetString(PyExc_IndexError, "string index out of range");
return NULL;
}

with:

if (PyObject_IsOutOfBounds((PyObject *)a, "string", i)
return NULL;

Or maybe add "index" and "length" attributes to the PyExc_IndexError?
"index" and "length" would of course be the invalid index and "length"
the length of the container. That would be harder and probably involve
some API change or something.

Sorry I haven't thought this through 100%, but I don't see how
actually _implementing it_ (getting it through the layers of
bureaucracy may be harder) could be so difficult.

Even though I could fix it, I don't feel tempted to do so: I never had
this problem; in most cases of IndexError, it was very clear what the
problem was so I didn't need the additional information.

For you yes, for a newbie the extra information would certainly be helpful.

--
mvh Björn

[BJörn Lindqvist]

On 12/4/06, OKB (not okblacke) <br************@nobrenspambarn.netwrote:

I think the same could be said of virtually all exceptions. WhatI
think would be ideal is that whenever an exception is raised, the
traceback tells you:

1) What the exception is
2) The names of the variables involved in the offending expression
(or their character position in the line)
3) The values of those variables

There was a patch to that effect and a thread about it on python-dev
two years ago [1]. Most python-devvers seemed skeptical. But the issue
haven't come to closure yet.

[1] - http://mail.python.org/pipermail/pyt...ry/051470.html

--
mvh Björn

[Fredrik Lundh]

BJörn Lindqvist wrote:

Sorry I haven't thought this through 100%

obviously not.

</F>

[Russ]

Fredrik Lundh wrote:

Sorry I haven't thought this through 100%

obviously not.

And you didn't like the "tone" of some of my earlier posts?

[Fredrik Lundh]

Russ wrote:

And you didn't like the "tone" of some of my earlier posts?

http://sourceforge.net/tracker/?grou...70&atid=355470

</F>

[Fredrik Lundh]

BJörn Lindqvist wrote:

Sorry I haven't thought this through 100%

obviously not.

And you're not helping.

I've already explained why something like PyObject_IsIndexOutOfBounds
cannot work earlier in this thread.

</F>

[John Machin]

OKB (not okblacke) wrote:
[snip]

I think the same could be said of virtually all exceptions. What I
think would be ideal is that whenever an exception is raised, the
traceback tells you:

1) What the exception is
2) The names of the variables involved in the offending expression
(or their character position in the line)
3) The values of those variables

This would be especially useful in cases where you have some long
expression and you get a "cannot concatenate str and list" or whatever.
The irritating thing about this as it is is that you cannot tell which
variables in the expression are causing the problem.

I realize that in some cases the offending expression may not be a single variable,
but I am curious whether it would be possible for
something like this:

"1" + "2" + "3" + "4" + 5 + "6"

A few points:

1. You have difficulty determining the "offending expression" in that
example?

2. If I read your requirement properly, you want an error message that
includes the following information from the source:

example 1: "1" + "2" + "3" + "4" + 5 + "6"
left operand name: "1" + "2" + "3" + "4"
left operand value: "1234"
right operand name: 5
right operand value: 5

example 2 (simple variables): str1 = "a"; list1 = ["b"]; foo = str1 +
list1
left operand name: str1
left operand value: "a"
right operand name: list1
right operand value: ["b"]

example 3 (simple variables): str1 = "a"; str2 = "x"; list1 = ["b"];
foo = str1 + str2 + list1
left operand name: str1 + str2
left operand value: "ax"
right operand name: list1
right operand value: ["b"]

IMHO there would be no point in handling only "simple" cases like
example 2 -- firstly, you don't need it; there's only one possible
answer for "left operand name". Secondly, AFAICT, the same mechanism
would handle examples of arbitrary complexity.

My guesses: (a) Implementing this error reporting information in a new
compiler and interpreter would add considerably to the effort required,
and to the complexity and thus to the risk of error. (b) Retrofitting
it to an existing compiler and interpreter would be a nightmare.
Possible: yes. Cost/benefit ratio: very high.

3. The OP asked only for values; you are asking for names and values.
If you have a magic flak jacket, please let me know; I'd like to borrow
it occasionally :-)

Cheers,
John

[Terry Reedy]

"Russ" <uy*******@sneakemail.comwrote in message
news:11*********************@80g2000cwy.googlegrou ps.com...

>
Fredrik Lundh wrote:

Sorry I haven't thought this through 100%

obviously not.

And you didn't like the "tone" of some of my earlier posts?

While Fredrik's reply is a bit short, as is sometimes his habit,
here are some things that appear to me to not have been thought through
enough:
1. some negative indexes are legal.
2. replacing short inline code with a function call on *every* index lookup
will slow down the interpreter a bit.
3. will the same check code work for even all built-in sequences?
4. how does index checking fit in with slice checking?

By the way, it is already understood that error messages could be better,
and I have thought about this one myself. You are not the first to notice,
and improvements occasionally get submitted (and later accepted) by people
with both the knowledge and motivation to do so. But insulting such people
is not helpful.

Terry Jan Reedy

[Martin v. Löwis]

ru***@yahoo.com schrieb:

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

Seems to me he called the suggestion (made without any
knowlage of the OP's abilities regarding C and Python's
internals) that he summit a patch, silly.

I aggree.

His response was well within the bounds of normal
usenet discourse.

Maybe I'm unusually picky, but I also feel insulted if
my suggestions are called silly - this is just like calling
myself silly. I rarely make silly suggestions deliberately
(and try to mark them as ironic in usenet if I do); so if
somebody puts them down as "silly", I'll feel insulted.

I personally don't think it is silly to suggest that an
IT professional becomes familiar with the implementation
of the Python interpreter. That code is well-written,
well-documented, so it should be feasible (rather than
being silly) for anybody with a programming background
and sufficient determination to familiarize with that code.

I take the same position for about any open-source software:
you *can* get into Apache, Mozilla, the Linux kernel,
and now the Java virtual machine if you want to. If you
don't, it's not because you can't, but because you don't
want to.

It would be unrealistic (but not silly) to suggest that
if the source code weren't available at all. It is *not*
silly to suggest that people should make efforts to
contribute to open source software.

Regards,
Martin

[rurpy]

Terry Reedy wrote:

"Russ" <uy*******@sneakemail.comwrote in message
news:11*********************@80g2000cwy.googlegrou ps.com...

Fredrik Lundh wrote:

Sorry I haven't thought this through 100%

obviously not.

And you didn't like the "tone" of some of my earlier posts?

While Fredrik's reply is a bit short, as is sometimes his habit,
here are some things that appear to me to not have been thought through
enough:
1. some negative indexes are legal.
2. replacing short inline code with a function call on *every* index lookup
will slow down the interpreter a bit.
3. will the same check code work for even all built-in sequences?
4. how does index checking fit in with slice checking?

By the way, it is already understood that error messages could be better,
and I have thought about this one myself. You are not the first to notice,
and improvements occasionally get submitted (and later accepted) by people
with both the knowledge and motivation to do so. But insulting such people
is not helpful.

I saw no posts where there OP insulted anybody without being
insulted first. It is ironic the Mr. Kern was the most consistent
insulter while at the same time accusing the OP of rudeness.

Your own post would have been more helpful (or at least less
devisive) had you left off that last sentence.

[Fredrik Lundh]

Martin v. Löwis wrote:

It would be unrealistic (but not silly) to suggest that
if the source code weren't available at all. It is *not*
silly to suggest that people should make efforts to
contribute to open source software.

you're forgetting that you're dealing with "squeaky wheel contributors"
here, not the kind of nice and helpful persons that actually make open
source work.

</F>

[Robert Kern]

ru***@yahoo.com wrote:

I saw no posts where there OP insulted anybody without being
insulted first. It is ironic the Mr. Kern was the most consistent
insulter while at the same time accusing the OP of rudeness.

As I said, insult is in the ear of the listener, so I apologize if anyone
construed my comments as insults. However, facts are facts, and I stated them as
I believe them. If you can pick out the precise comments that you felt were
insulting, I will be happy to attempt clarifying them in a way that you do not
find insulting.

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

[BJörn Lindqvist]

On 12/4/06, Fredrik Lundh <fr*****@pythonware.comwrote:

BJörn Lindqvist wrote:

Sorry I haven't thought this through 100%

obviously not.

And you're not helping.

I've already explained why something like PyObject_IsIndexOutOfBounds
cannot work earlier in this thread.

Maybe so, but that doesn't mean that it is not possible to make the
IndexError messages Pythons sequence objects throws better. You don't
need to change the semantics of x[i].

--
mvh Björn

[BJörn Lindqvist]

On 12/4/06, Terry Reedy <tj*****@udel.eduwrote:

While Fredrik's reply is a bit short, as is sometimes his habit,
here are some things that appear to me to not have been thought through
enough:
1. some negative indexes are legal.

That could be fixed. Just substract len(L) from i if i < 0.

2. replacing short inline code with a function call on *every* index lookup
will slow down the interpreter a bit.

I can't notice any difference. On my machine, Python is compiled with
-O3 which probably inlines the function.

3. will the same check code work for even all built-in sequences?

Atleast for tuple, string and list, they can be downcasted to
PyVarObjects. So yes.

4. how does index checking fit in with slice checking?

When does slicing throw IndexErrors?

with both the knowledge and motivation to do so. But insulting such people
is not helpful.

Agreed. I don't think insulting people is helpful at all, but I don't
think "Russ" is the only one in this thread that should learn that.

--
mvh Björn

[Russ]

Fredrik Lundh wrote:

you're forgetting that you're dealing with "squeaky wheel contributors"
here, not the kind of nice and helpful persons that actually make open
source work.

Please refrain from dishing out gratutious insults until you have a
clue what you are talking about. It just so happens that I *have* made
significant contributions to open-source software.

A few years ago, I spent several man-months of my own time developing a
free, open-source, full-featured GUI for voting:

http://russp.org/GVI.htm

GVI, The Graphical Voter Interface, is a GUI (Graphical User Interface)
for voting, suitable for use in private or public elections. Although
it could be adapted for online voting, it is currently intended only
for conventional "precinct" voting. For security reasons, GVI does not
require that the voter have access to a keyboard. It can handle
write-ins and multi-language elections, and it can automate voting
along party lines. GVI can be used for Condorcet Voting and Instant
Runoff Voting, which allow voters to rank the candidates in order of
preference. It can also be used for Approval Voting, which allows
voters to select more than one candidate.

More recently, I developed a free, open-source Python package for
dealing with physical scalars. It has an innovative feature that
preserves the efficiency of built-in numerical types with an optional
switch:

http://russp.org/scalar.htm

A Python class was designed to represent physical scalars and to
eliminate errors involving implicit physical units (e.g., confusing
angular degrees and radians). The standard arithmetic operators are
overloaded to provide syntax identical to that for built-in numeric
types. The scalar class comes with a complete implementation of the
standard metric system of units and many standard non-metric units. It
also allows the user to easily define a specialized or reduced set of
appropriate physical units for any particular application or domain.
Once an application has been developed and tested, the units can easily
be switched off, if desired, to achieve the execution efficiency of
operations on built-in numeric types (which can be two orders of
magnitude faster). The scalar class can also be used for discrete units
to enforce type checking of integer counts, thereby enhancing the
built-in dynamic type checking of Python.