Slice inconsistency?

[Stephen Horne]

On Sat, 27 Sep 2003 13:15:34 -0400, "Terry Reedy" <tjreedy at udel.edu>
wrote:

>As I pointed out in response to the same message, there is no
>inconsistency because the premise behind that conclusion is wrong.  I
>also pointed out that you can make the premise true and get the
>consistency you expect by adding a comma after single slice
>expressions so that you do always use tuple notation.

"object [slice(...),slice(...)]" is a notation for subscripting with a
tuple of slices. The user has explicitly created slice objects without
using slice notation, and has wrapped them in a tuple, so has no right
to expect any additional behaviour that slice notation might provide.

But Roberto didn't do that.

To me, "object [a:b:c,d:e:f]" doesn't look like a tuple notation. It
looks like a slice notation. 'a:b:c' is not a notation for an object
in itself, and therefore 'a:b:c,d:e:f' is not a notation for a tuple.

The fact that this slicing is implemented by passing a tuple
containing slice objects to __getitem__ is besides the point - each
individual 'a:b:c' should be handled in the same way as if there were
only one 'a:b:c' there.

However, a little experiment surprised me...

>>> class a :
...   def __getitem__ (self, idx) :
...     print idx
...
>>> x=a()
>>> x[1:2:3,]
(slice(1, 2, 3),)

The apparant purpose of the notation is to allow multi-dimensional
slicing. I can see how having a single-dimensional slice call that is
implemented consistently with the multi-dimensional slices is
convenient when writing the __getitem__, but the whole point of
libraries is handle complexity so that the caller doesn't have to. Why
does the caller have to deal with two incompatible single-dimensional
slice notations?

Could the two single-dimensional slice notations have usefully
distinct meanings? Do those distinct meanings justify applying the
negative subscript fix in one case but not the other?

Something is going on that seems strange to me. I suspect that these
are signs of a repeated-extension-over-history with
backward-compatibility issue. Maybe Numeric was the first place where
it was recognised that the negative subscription trick is not always
appropriate - but until new-style classes the basic slice notation
could not be made consistent without big back-compatibility issues.

I'm rather glad that with new-style classes things have been made
consistent.


-- 
Steve Horne

steve at ninereeds dot fsnet dot co dot uk