[Python-3000] Changing function-related TypeErrors

Thomas Wouters thomas at python.org
Tue May 9 22:16:10 CEST 2006


On 5/9/06, joe user <signspointtoprobably at yahoo.com> wrote:
>
> Does this mean you have no more actual technical reasons to oppose this change, but are just stomping your foot and implying bad things about Winter?  Because there are people who agree with him, and I haven't seen any really compelling reasons to avoid this ten-line modification.
>
> Well, I shan't speak for Guido, but I haven't seen a compelling reason to
change the existing exception class, either. The exception *class* will
never explicit enough, it will never reflect all the specific details about
the error. You always need the actual error message to determine that. If
it's really necessary to be able to 'parse' an exception, adding attributes
to the instance to indicate what the problem seems to be is a more scalable
approach, IMHO, but I don't really see the need myself.

I've had many, many newbies come along complaining about the TypeError that
woudl become an ArgumentError, and never, ever, were they confused about the
fact that it was a TypeError. They were always confused about "expected
three, got four" when the functioncall clearly showed three arguments (it
was a methodcall, of course.) Why change the class? What other classes
should be changed? How fine-grained should it be? The effort, regarless of
how small it is, is in my opinion wasted. (As is all the effort in
discussing this, including this message :-)

--
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060509/2db3477b/attachment.html 


More information about the Python-3000 mailing list