On Feb 1, 2015 9:48 PM, "Antoine Pitrou" firstname.lastname@example.org wrote:
On Mon, 2 Feb 2015 07:38:52 +1100 Chris Angelico email@example.com wrote:
On Mon, Feb 2, 2015 at 5:13 AM, Thomas Kluyver firstname.lastname@example.org
Iterating over a slice object would work like you were lazily taking
slice from itertools.count() - i.e. iter(a:b:c) would be equivalent to islice(count(), a, b, c). This would also mean that (3:) would have a logical meaning without having to modify range objects to support an optional upper bound. I don't see any logical way to iterate over a
defined with negative numbers (e.g. (-4:)), so presumably iter(-4:)
raise an exception.
If you're going to start defining things in terms of itertools.count(), I'd prefer to first permit a range object to have an infinite upper bound, and then define everything in terms of a sliced range - range objects already support clean slicing.
Is there any particular reason for range objects to disallow infinite bounds, or is it just that nobody's needed it?
If the platform's Py_ssize_t type is large enough to represente positive infinites, then you probably could support infinite range objects.
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?