This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients belopolsky, rhettinger
Date 2008-04-30.13:42:06
SpamBayes Score 0.002276703
Marked as misclassified No
Message-id <d38f5330804300641l45c77e8awf3bc392645b072e3@mail.gmail.com>
In-reply-to <1209537132.33.0.867916991223.issue2723@psf.upfronthosting.co.za>
Content
On Wed, Apr 30, 2008 at 2:32 AM, Raymond Hettinger
<report@bugs.python.org> wrote:

>  Wouldn't it be better to raise OverflowError or somesuch?

Thats what the current code does.  I don't know what Guido's full
rationale is, but I guess the idea is that len(..) is not supposed to
raise an exception on sizeable objects.

Here is a quote from another message:

"""
__len__ will always be problematic when there are more values than can
be counted in a signed C long; maybe we should do what the Java
collections package does: for once, Java chooses practicality over
purity, and simply states that if the length doesn't fit, the largest
number that does fit is returned (i.e. for us that would be
sys.maxsize in 3.0, sys.maxint in 2.x).
"""
-- Guido van Rossum, 2008-04-30
http://mail.python.org/pipermail/python-3000/2008-April/013340.html

I suspect, however, that part of Java's motivation for this behavior
is that exceptions need to be declared and declaring the length method
as throwing OverflowError would make many programmers very unhappy.
History
Date User Action Args
2008-04-30 13:42:20belopolskysetspambayes_score: 0.0022767 -> 0.002276703
recipients: + belopolsky, rhettinger
2008-04-30 13:42:17belopolskylinkissue2723 messages
2008-04-30 13:42:10belopolskycreate