Re: [Python-3000] Using range()

On Fri, Apr 25, 2008 at 12:04 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > Eh, brain explosion from typing too late at night. The experiment I > actually *meant* to try was: > > >>> x = range(0, 2**33, 2) > >>> len(x) > Traceback (most recent call last): > File "", line 1, in > OverflowError:

Re: [Python-3000] Using range()

Mark Dickinson wrote: On Thu, Apr 24, 2008 at 11:50 AM, Nick Coghlan <[EMAIL PROTECTED] > wrote: There's definitely some bugs in this area of the range object code though: >>> x = range(2**33, 2) >>> len(x) 0 >>> x[0] Traceback (most re

Re: [Python-3000] Using range()

On Thu, Apr 24, 2008 at 1:01 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote: > It seems to me that there are two reasonable behaviours > for range(a, b) when b is less than a: return an 'empty' range, > as in the example above, or raise a ValueError; Don't even think about suggesting to change this

Re: [Python-3000] Using range()

On Thu, Apr 24, 2008 at 11:50 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > There's definitely some bugs in this area of the range object code though: > > >>> x = range(2**33, 2) > >>> len(x) > 0 > >>> x[0] > Traceback (most recent call last): > File "", line 1, in > IndexError: range object ind

Re: [Python-3000] Using range()

> Where is that OverflowError coming from? It computes the length of the range, to find out whether the index is out of range. Computing the length then raises the exception, as it uses range_length, not range_length_obj. Regards, Martin ___ Python-3

Re: [Python-3000] Using range()

Martin v. Löwis wrote: > This is a bug, right? I'd call it an implementation limitation. This is because I'm in a 32 bit machine? Right. The assumption is that you typically use the range elements to index into some collections, and you can't have collections with more than 2**32 elements (a

Re: [Python-3000] Using range()

> It is a bit surprising, especially given > that the following works: > r = range(10**19-100, 10**19) r[0] > 900 The original example fails because range_length() overflows in range_item. Given that range_item is "almost" there, it's probably not as difficult to fix th

Re: [Python-3000] Using range()

On Thu, Apr 24, 2008 at 11:37 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > While I could understand a 'must fit in ssize_t' limitation on the index > passed to the range object (or conceivably even on the value returned, > although that would be a little odd), that isn't happening in the example

Re: [Python-3000] Using range()

Martin v. Löwis wrote: Which is the normal way to "consume" a range object, item by item? The normal way is a for loop. The advanced way of invoking some method on the object (i.e. emulating the for loop) is to first create an iterator from the range object. You can't consume the range itself:

Re: [Python-3000] Using range()

>> > This is a bug, right? >> >> I'd call it an implementation limitation. > > This is because I'm in a 32 bit machine? Right. The assumption is that you typically use the range elements to index into some collections, and you can't have collections with more than 2**32 elements (actually, addre

Re: [Python-3000] Using range()

On Thu, Apr 24, 2008 at 10:58 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > r = range(1000) > r[0] > > Traceback (most recent call last): > > File "", line 1, in > > OverflowError: Python int too large to convert to C ssize_t > > > > This is a bug, right? > >

Re: [Python-3000] Using range()

2008/4/24, "Martin v. Löwis" <[EMAIL PROTECTED]>: > The advanced way of invoking some method on the object (i.e. emulating > the for loop) is to first create an iterator from the range object. > You can't consume the range itself: it will always contain the same > numbers - just like you can't

Re: [Python-3000] Using range()

> Which is the normal way to "consume" a range object, item by item? The normal way is a for loop. The advanced way of invoking some method on the object (i.e. emulating the for loop) is to first create an iterator from the range object. You can't consume the range itself: it will always contain