On Tue, Sep 2, 2008 at 12:08 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > 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:
This should raise an IndexError. I think you meant something else? > 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 > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
