[Python-3000] Should len() clip to sys.maxsize or raiseOverflowError?

Guido van Rossum guido at python.org
Tue Sep 2 21:20:32 CEST 2008


On Tue, Sep 2, 2008 at 12:08 PM, Raymond Hettinger <python at rcn.com> wrote:
> From: "Guido van Rossum" <guido at python.org>
>>
>> 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/)


More information about the Python-3000 mailing list