<div dir="ltr">On Tue, Sep 2, 2008 at 3:53 PM, Guido van Rossum <span dir="ltr">&lt;<a href="mailto:guido@python.org">guido@python.org</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The only time when __len__ can be larger than sys.maxsize is when the<br>
class implements some kind of virtual space where the values are<br>
computed on the fly. In such cases trying to walk over all values is<br>
bound to take forever, and the length is likely not of all that much<br>
interest to the caller -- but sometimes we may need to pass such an<br>
object to some library code we didn&#39;t write that is making some<br>
trivial use of len(), like the examples I gave before.</blockquote><div><br>len() is useful for more than iteration, such as setting the bounds for a binary search (e.g., over a large on-disk data structure)<br><br> </div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
That said, I would actually be okay with the status quo (which does<br>
raise an OverflowError) as long as we commit to fixing this properly<br>
in 2.7 / 3.1, by removing the range restriction (like we&#39;ve done for<br>
other int operations a long time ago).<br>
</blockquote></div><br>+1<br><blockquote style="margin: 1.5em 0pt;">--<br>
Daniel Stutzbach, Ph.D.<br>
President, <a href="http://stutzbachenterprises.com">Stutzbach Enterprises, LLC</a>
</blockquote></div>