[Python-Dev] Re: More informative error messages
ianb at colorstudy.com
Wed Oct 8 12:33:37 EDT 2003
On Wednesday, October 8, 2003, at 09:52 AM, Gerrit Holl wrote:
> [I'm not a regular poster, so I'll introduce myself shortly: I am a
> first-year Physics student without CS knowledge, have learned
> programming with Python a few years ago]
> Gregory Smith wrote:
>>> At the time the TypeError is constructed it shouldn't add serious
>>> overhead to check if its a method or a function and subtract 1
> Guido van Rossum replied:
>> You'd think so, eh? Have you looked at the code? Have you tried to
>> come up with a patch? Why do you think that in 13 years this hasn't
>> been fixed if it's such a common complaint?
> Would it be possible to have this code at IDE-level? E.g., is possible
> for Idle to catch TypeError's and try to find out whether this is about
> the number of arguments to a callable, and if so, try to find out
> it is about a method or a function? This is of course a lot of
> but since it is only for an interactive session, I think this is not a
> problem, or am I mistaken here?
Or more generally, what if we just add more helpful information to
tracebacks? If we care about the particulars of the message, it is
always in the context of a traceback. And we don't care about the
efficiency of tracebacks.
What if, say, exceptions had a method strfortraceback(tb), which was
smarter when that would be helpful? Like the code you have here, only
as a method of TypeError (or some subclass)...
> Something like:
> except TypeError, msg:
> if "takes exactly" in msg: # something with tb_lasti?
> name = msg.split('(')
> typ, val, tb = sys.exc_info()
> if name in tb.tb_frame.f_locals.keys():
> if 'instancemethod' in type(tb.tb_frame.f_locals[name]):
> # subtract 1
> # don't subtract 1
> # hmm, if it is a method, how do we find it?
> # etc.
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Python-Dev