From: "Guido van Rossum" <[EMAIL PROTECTED]>
The way I see it is that there are tons of ways I can think of how
raising OverflowError can break unsuspecting programs (e.g. code that
has been tested before but never with a humungous input), whereas
returning a "little white lie" would allow such code to proceed just
fine. Some examples of code that is inconvenienced by the exception:
if len(x): # used as non-empty test
if len(x) > 100: # used to guarantee we can access items 0 through 99
for i in range(len(x)): # will be broken out before reaching the end
That makes sense to me and there a probably plenty of examples.
However, I worry more about other examples that will fail
and do so it a way that is nearly impossible to find through
code review (because the code IS correct as written).
n = len(log_entries)
if log_entries[n] in handled:
log_entries.pop(n)
It's not hard to imagine other examples with slicing and whatnot.
These cases may be less common that those pointed out by Guido
but they will be disasterous when they occur and very hard to
defend against or debug.
I would rather face the overflow errors when they arise than
deal with the latter cases. In the former, I can always make an immediate
fix by replacing the builtin with an Overflow suppressing version.
But, in the latter case, the silent failure is *much* harder to deal with.
Raymond
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
