Ram Rachum added the comment:
Thanks for the information about timing, Stefan and Josh. That is good to know
regardless of this ticket :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21911
Josh Rosenberg added the comment:
Looking at a single lookup performed over and over isn't going to get you a
very good benchmark. If your keys are constantly reused, most of the losses
won't show themselves. A more fair comparison I've used before is the
difference between using the bytes
Serhiy Storchaka added the comment:
Ram, do you want to provide a patch and benchmarks?
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21911
___
Berker Peksag added the comment:
See also issue 18162.
--
nosy: +berker.peksag
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21911
___
___
Ram Rachum added the comment:
obably Serhiy: Unfortunately I don't program in C, so I can't implement this.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21911
___
Ezio Melotti added the comment:
The feature request sounds reasonable to me, unless someone proves that there
are major (performance) issues. However, since this has already been reported
in #18162, I'm going to close it as a duplicate.
@Raymond
The IndexError exception is commonly used for
Stefan Behnel added the comment:
you'd be surprised how much cheaper indexing a sequence is relative to
dictionary access
This is a bit off-topic (and I realise that this ticket is closed now), but the
difference isn't really all that large:
$ python3.4 -m timeit -s 'seq = list(range(1000));
Terry J. Reedy added the comment:
I have several times found exception messages to be under-informative, and I am
pretty sure this is one of them. The obvious use case is so I don't have to
insert a print statement, which I can only do if the error is in Python code,
to get the essential info
Éric Araujo added the comment:
Mark, could you please not phrase your messages as if you were speaking for the
whole core team, and be more friendly with other contributors (or reply less)?
--
nosy: +eric.araujo
___
Python tracker
New submission from Ram Rachum:
Ditto for lists and any other place this could be applicable.
--
components: Interpreter Core
messages: 222168
nosy: cool-RR
priority: normal
severity: normal
status: open
title: IndexError: tuple index out of range should include the requested
index and
Raymond Hettinger added the comment:
Why? Is there any known use case?
The IndexError exception is commonly used for control flow. Slowing down the
instantiation to add an index that no one really needs would be a waste. This
exception has been around for 20+ years -- if they were an
Ram Rachum added the comment:
Raymond: I do take your point about performance, and I understand that if this
results in a performance problem, then that's a good argument to not include
this feature.
But I'm baffled as to why you're asking me regarding this feature Why? Is
there any known
Josh Rosenberg added the comment:
TypeError also should be more specific because it can occur for a multitude of
reasons; along with stuff like AttributeError, it's one of those exceptions
that could arise from multiple causes on a single line of code, none of them
obvious. For the specific
Ram Rachum added the comment:
Josh... The reason I gave all these examples of where Python gives detailed
error messages, is not so you'd explain the obvious reason, which is that it
makes it easier to debug, figure out what's wrong with your program, and fix
it. The reason I gave these
Mark Lawrence added the comment:
If a programmer can't work out from IndexError: tuple index out of range what
is going on they should give up programming. Personally I'd close this now
with resolution complete waste of core dev time.
--
nosy: +BreamoreBoy
type: behavior -
Ram Rachum added the comment:
Mark, again I'm finding myself saying things that are obvious to all of us: You
can figure out that tuple index out of range means you asked for an item
bigger than the size of the tuple, but it might be very helpful for debugging
to say the number of item that
Mark Lawrence added the comment:
Ram I won't be making any more comments as it's quite clear to me that you have
no empathy at all with the core devs.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21911
Josh Rosenberg added the comment:
As I said, the main reason is that every feature has to start at minus 100
points. It's not that your idea is bad, it's that it has to be sufficiently
good to warrant the risks that come with any code churn, no matter how small.
Simple and obvious does not
Ram Rachum added the comment:
Josh, I agree with most of what you're saying. (Except the tips about debugging
are not helpful, the point is to get the information as quickly as possible
without having to make code modifications if possible.)
I can totally understand a reaction of Your idea is
R. David Murray added the comment:
The development team is not monolithic, and we are all people, with differing
opinions (and Mark is Mark). As has been pointed out, there is people-load for
development and maintenance associated with any change, so a mature project has
a natural tendency
Ram Rachum added the comment:
David, as a more generalized solution: Do you think it's possible to make some
kind of mechanism in Python that would change the way that an exception is
constructed based on whether it's used for control flow or not? I know that
it's a bit far-fetched, but if we
21 matches
Mail list logo
