Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Slice inconsistency?

Reply
Thread Tools

Slice inconsistency?

 
 
Stephen Horne
Guest
Posts: n/a
 
      09-27-2003
On Sat, 27 Sep 2003 12:56:25 -0400, "Terry Reedy" <(E-Mail Removed)>
wrote:

>Sorry, wrong. Tuple notation for single slices givea a different
>result.


A different implementation, but this is a high level language. The
caller is supposed to worry about the purpose of the syntax, not (as
far as possible) the implementation.

The idea that single slices *should* behave in a different way to
extended slices seem bizarre to me - the kind of thing that arises out
of historic issues rather than out of principle. And if they really
*should* have different meanings, why does this inconsistency
disappear at the first opportunity to remove it without back
compatibility issues (ie in new style classes), for which __getitem__
is called with a slice object (and no -ve index translation) for both
single and extended slices.

This isn't a criticism of Python - it is simply an example of how new
style classes has allowed vestiges from a less flexible past to be
tidied up. Python has grown without becoming a house of cards - that
is a good thing.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk
 
Reply With Quote
 
 
 
 
John Roth
Guest
Posts: n/a
 
      09-27-2003

"Stephen Horne" <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> wrote in
message news:(E-Mail Removed)...
> On Sat, 27 Sep 2003 13:15:34 -0400, "Terry Reedy" <(E-Mail Removed)>
> 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.


I suppose the whole thing was totally accidental, in the sense that
it fell out of the way things work without any explicit design intent
that it work that way.

Python has a number of surprising things that cause trouble in
reasoning about how things work. One of them is that it is
the comma that creates the tuple, not the parenthesis, and the
colon creates the slice object, not the brackets. Likewise,
the interpreter does not distinguish between subscripts
and slices, that's up to the __getitem__() magic
method.

So you're basically passing something to __getitem__()
that nobody thought about, and expecting it to work.
It sounds like something I might like to use some day
myself, but it's not going to suddenly appear by magic.

Submit a PEP.

John Roth


>
>
> --
> Steve Horne
>
> steve at ninereeds dot fsnet dot co dot uk



 
Reply With Quote
 
 
 
 
Stephen Horne
Guest
Posts: n/a
 
      09-27-2003
On Sat, 27 Sep 2003 16:00:39 -0400, "John Roth"
<(E-Mail Removed)> wrote:

>So you're basically passing something to __getitem__()
>that nobody thought about, and expecting it to work.
>It sounds like something I might like to use some day
>myself, but it's not going to suddenly appear by magic.
>
>Submit a PEP.


For what? - new style classes already do what I (and apparently
Roberto) would expect. I don't care if old style classes act in a
backward-compatible rather than idealistic way - that is what old
style classes are for.

All Roberto needs to do is make his class a subclass of object and it
will do exactly what he needs - somebody did think about it and that
PEP has apparently already been submitted and implemented a long time
ago.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk
 
Reply With Quote
 
Roberto A. F. De Almeida
Guest
Posts: n/a
 
      09-28-2003
Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> wrote in message news:<(E-Mail Removed)>. ..
> All Roberto needs to do is make his class a subclass of object and it
> will do exactly what he needs - somebody did think about it and that
> PEP has apparently already been submitted and implemented a long time
> ago.


Yes, I think this is the best thing to do. It removes the (apparent or
not) inconsistency, and does what I would expect from the principle of
least surprise. The other solutions, like the Proxy class and Terry's
suggestion of adding a comma to uni-dimensional slices (c[:-1,]) are
interesting, but they are not consistent with Numeric slices. I'll
keep them in mind, though.

Thanks,

Roberto
 
Reply With Quote
 
Greg Ewing (using news.cis.dfn.de)
Guest
Posts: n/a
 
      09-30-2003
Stephen Horne wrote:
> The idea that single slices *should* behave in a different way to
> extended slices seem bizarre to me - the kind of thing that arises out
> of historic issues rather than out of principle.


And it is indeed a historic issue.

If you want the gory details:

Once upon a time, there was no such thing as a slice object.
Indexing and slicing were treated as completely separate
things, and handled by separate methods at the C level:

seq[x] --> the C-level equivalent of __getitem__(self, x)
seq[x:y] --> the C-level equivalent of __getslice__(self, x, y)

(There were no 3-element slices, either.)

Moreover, the arguments to the C-level __getslice__ method
*had* to be integers, and the interpreter performed the convenience
of interpreting negative indices for you before calling it.

Then Numeric came along, and people wanted to be able to
slice multi-dimensional arrays. So the slice object was
invented, and the parser and interpreter taught to create
them when encountering slice notation, and feed tuples of
them to __getitem__.

But, for backwards compatibility, the special case of a
single 2-element had to be handled specially. If the object
being sliced had (at the C level) a __getslice__ method,
it would be used. If it didn't, a slice object would be
created and passed to __getitem__.

This was fine for C objects, such as Numeric arrays,
which can choose to not provide a __getslice__ method.
But due to the way old-style classes are implemented,
they *always* have a __getslice__ method at the C level,
regardless of whether they have one at the Python level.
So it's impossible to write an old-style Python class that
doesn't get its single two-element slices mangled.

Fortunately, new-style classes are much more like C
objects, and they don't suffer from this problem.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      09-30-2003

"Greg Ewing (using news.cis.dfn.de)" <(E-Mail Removed)> wrote
in message
> If you want the gory details:


Thank you for the nice explanation of why slices currently behave as
they do.

Terry J. Reedy


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Modelsim Slice error using numeric_std Beanut VHDL 5 09-22-2005 01:16 PM
Null slice? Synthesis in XST? Brandon VHDL 0 08-31-2005 09:16 PM
Concurrent assignments to std_ulogic_vector slice is OK with ModelSim Nicolas Matringe VHDL 9 06-14-2004 10:10 PM
How to get a slice of INTEGER type out? walala VHDL 1 09-05-2003 08:04 PM
slice of multidimensional array Dave Bazell Perl 2 07-24-2003 11:17 PM



Advertisments