<p dir="ltr"><br>
On Feb 1, 2015 9:48 PM, "Antoine Pitrou" <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
><br>
> On Mon, 2 Feb 2015 07:38:52 +1100<br>
> Chris Angelico <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> wrote:<br>
> > On Mon, Feb 2, 2015 at 5:13 AM, Thomas Kluyver <<a href="mailto:thomas@kluyver.me.uk">thomas@kluyver.me.uk</a>> wrote:<br>
> > > Iterating over a slice object would work like you were lazily taking that<br>
> > > slice from itertools.count() - i.e. iter(a:b:c) would be equivalent to<br>
> > > islice(count(), a, b, c). This would also mean that (3:) would have a<br>
> > > logical meaning without having to modify range objects to support an<br>
> > > optional upper bound. I don't see any logical way to iterate over a slice<br>
> > > defined with negative numbers (e.g. (-4:)), so presumably iter(-4:) would<br>
> > > raise an exception.<br>
> ><br>
> > If you're going to start defining things in terms of<br>
> > itertools.count(), I'd prefer to first permit a range object to have<br>
> > an infinite upper bound, and then define everything in terms of a<br>
> > sliced range - range objects already support clean slicing.<br>
> ><br>
> > Is there any particular reason for range objects to disallow infinite<br>
> > bounds, or is it just that nobody's needed it?<br>
><br>
> If the platform's Py_ssize_t type is large enough to represente<br>
> positive infinites, then you probably could support infinite range<br>
> objects.<br>
></p>
<p dir="ltr">Or you could just make a special case if the upper bound is None.  The question is what would happen if you tried to get the len() of such a range.  An exception?  -1? None?</p>