On Feb 1, 2015 7:14 PM, "Thomas Kluyver" <thomas@kluyver.me.uk> wrote:
> On 1 February 2015 at 07:13, Todd <toddrjen@gmail.com> wrote:
>> For examples, the following pairs are equivalent:
>> range(4, 10, 2)
>> (4:10:2)
> I think I remember a proposal somewhere to allow slice notation (defining slice objects) outside of [] indexing. That would conflict with this idea of having slice notation define range objects. However, if slice notation defined slice objects and slice objects were iterable, wouldn't that have the same benefits?

I considered that.  I thought of three scenarios (in the following order):

Slice is iterable: this has the advantage that classes implementing slicing could just iterate over any slice they get.  The problem here is that you end up with two data structures with separate implementations but nearly identical functionality. This would be unnecessary code duplication and thus, I felt,  unlikely to be accepted.

Slice is a subclass of range: this avoids the problem of the independent implementations.  The problem is that it would be a subclass in name only.  I could not think if any additional methods or attributes it should have compared to conventional ranges.  The only thing it would do that ranges currently can't is not have an end, but since that would need to be implemented somewhere it might as well be added to the range parent class.  So I felt that would be a deal-killer.

Use slices to make ranges: this would not be as useful in classes, but it would really only save one line at best.  It has the advantage that it would not require ranges to support anything they can't already.  Although you could support infinite ranges, you could just as easily just not accept open-ended slices.

Since the first two cases essentially reduce to the third, I felt the third approach would be the most straightforward.

I also considered two other, related issues:

Using a slice object with this syntax.  However, something like (slice_obj) seemed like it could break existing code, and (:slice_obj) just seemed weird.

Passing a slice to a range.  So you could do range(slice_obj), but this seems like something that would have very little benefit and only save a little account of code.

> Iterating over a slice object would work like you were lazily taking that 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 slice defined with negative numbers (e.g. (-4:)), so presumably iter(-4:) would raise an exception.
> Thomas

I though