[Python-ideas] More useful slices

[Todd]

On Feb 1, 2015 7:14 PM, "Thomas Kluyver" <thomas at kluyver.me.uk> wrote:
>
> On 1 February 2015 at 07:13, Todd <toddrjen at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150201/2b56bce3/attachment-0001.html>