why would it raise an index error when log_entries has more indicies then sys.maxsize, it should just check the entry @ sys.maxsize.
Maybe I missed it, but why cant len just return an int, which if I remember correctly is now a long in py3k, so on a 64 bit system len would (hopefully) never lie, but on a 32 bit system it could return a number segnificently lower then the actual number of entries. On 9/2/08, Guido van Rossum <[EMAIL PROTECTED]> wrote: > 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/digitalxero%40gmail.com > -- Dj Gilcrease OpenRPG Developer ~~http://www.openrpg.com OpenRPG+ Lead Developer ~~http://openrpg.digitalxero.net XeroPortal Creator ~~http://www.digitalxero.net Web Admin for Thewarcouncil.us ~~http://www.thewarcouncil.us _______________________________________________ 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
