On Wed, 30 Oct 2013 20:22:22 +1000, Nick Coghlan <ncoghlan@gmail.com> wrote:
Regardless, my main point is this: slices are just objects. The syntax:
s[i:j:k]
is just syntactic sugar for:
s[slice(i, j, k)]
That means that until people have fully explored exactly the semantics they want in terms of the existing object model, just as I did for rslice(), then there are *zero* grounds to be discussing syntax changes that provide those new semantics.
(Sending from gmane on limited tablet) I think its sugar for a function that takes *args and depending on its contents makes a slice, or multiple slices, plus what ever is left over. In the case of a simple index its just whats left over. Slice syntax is simple on purpose so that they can pass through more than just ints. It the responsibility of the object that uses them to make sense of the slices. So it may possible to pass a callable index modifier through too. def reversed(obj, slice_obj): ... return reversed_slice_obj a[i:j:k, reversed] If it's also passed the object to be sliced, self from __getitem__ method, it could set end values and maybe do other things like control weather exceptions are raised or not. Its kind of like decorating a slice. For example it could do an infanite wrap around slice by normalizing the indices of the slice object. Ican't test it on this tablet unfornately. Cheers, Ron Adam.