On Wed, 23 Aug 2006 11:16:17 +0200, Sybren Stuvel wrote:
> Steven D'Aprano enlightened us with:
>> But an upside is that it would enable more useful error messages, at least
>> sometimes. Here's some trivial pseudo-code:
>>
>> def foo(a):
>> assert len(a) > 10, "%s is too short" % a.__name__
>>
>> y = "hello"
>> foo(y)
>>
>> would display "AssertionError: y is too short".
>
> That's simply a very bad example.
No, it is a *simplified* example. There's a difference between simplified
and bad. Would you have preferred me to post five pages of complex
function calls demonstrating the same point, namely that you can bind an
object to a name in one place, then pass it to a function where any
tracebacks will refer to the name in the local namespace rather than the
name in the traceback where the invalid data first existed?
> If you use a real-world function,
> you notice that the current error messages are just fine:
>
> def update(title):
> assert len(title)> 10, "Title too short"
>
> update("hello")
>
> would display: "AssertionError: Title too short". Seems fine to me.
Sure, in this case you back-track one level, and see that you passed a
string literal. Easy.
And in other cases, you don't pass a literal, you pass a name (say,
"windowtitle"), and now instead of looking for the name title you're
looking for the name windowtitle. Where did it come from? What's
it's value?
And in some cases, windowtitle wasn't bound to a literal either, it was
bound to (say) filename.upper(), so now you're no longer looking for
either title or windowtitle, but filename. Where did it get its value
from?
--
Steven D'Aprano
--
http://mail.python.org/mailman/listinfo/python-list
