Greg Ewing (using news.cis.dfn.de)
g2h5dqi002 at sneakemail.com
Tue Sep 30 09:01:12 CEST 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
More information about the Python-list