<br>A long-standing part of Py3K is removing 'old style slices' (meaning the __get/set/delslice__ methods and the sq_slice/sq_ass_slice sequence-struct functions, but not slice objects.) I started removing them, only to find out that it's damned inconvenient to make all slicing go through tp_as_mapping->mp_subscript, for two reasons:
<br><br> - Many classes don't behave as mapping at all, so the mp_subscript function (and the whole tp_as_mapping struct) would be added just for the benefit of accepting slices, which is really a sequence thing, not a mapping thing.
<br><br> - There's actually a PyMapping_Check that relies on sq_slice: a type is a mapping type when it has tp_as_mapping->mp_subscript but not tp_as_sequence->sq_slice. I'm not sure how to express that if there is no special method for slicing.
<br><br>So, I imagine we need a special (C level) hook for slicing after all, just one that always takes a slice object (or tuple of slice-objects-or-tuples-of-same. Oh, and/or Ellipsis. Did I forget anything? :) Either that, or a set of conveniency functions (which we already have, for the most part) and a mapping/sequence-agnostic getitem/subscript. But if we do that, we need a new way of implementing PyMapping_Check.
<br><br>(While on the subject, howmuch of the C API dealing with slices should be adjusted? There's PySequence_GetSlice() that takes Py_ssize_t's, which is (IMHO) pretty convenient for C code, but it'd have to create a slice object behind the scenes. And maybe creating a slice object manually isn't that much effort, after all.)
<br><br>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!