On Tue, Sep 2, 2008 at 11:14 AM, Daniel Stutzbach
<[EMAIL PROTECTED]> wrote:
> On Tue, Sep 2, 2008 at 12:26 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> I stand by my view. I might voice strong discomfort with raising an
>> exception because it doesn't fit in some implementation detail.
>
> Isn't that precisely what OverflowError is for? ("it doesn't fit in some
> implementation detail")
>
> It seems to me that the Purity angle here would be to allow len() to return
> any Python int object. The Practical angle wants to restrict it to
> sys.maxsize for performance reasons. Throwing an OverflowError seems like a
> good way for Practical to cry, "Oops, I've been caught".
>
> (I'm interested in this issue because my list-like extension type can in
> some cases have a length greater than sys.maxsize)
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
--
--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
