(original) (raw)

On Sat, Mar 3, 2012 at 19:58, Guido van Rossum <guido@python.org> wrote:
> On Sat, Mar 3, 2012 at 4:20 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
>>> I'd expect slice subscripts to be part of the sequence interface, and
>>> yet they are not. In fact, they are part of the mapping interface. For
>>> example, the list object has its slice get/set methods assigned to a
>>> PyMappingMethods struct. So does a bytes object, and pretty much every
>>> other object that wants to support subscripts.
>>
>> It comes from:
>> http://hg.python.org/cpython/rev/245224d1b8c9
>> http://bugs.python.org/issue400998
>>
>> Written by Michael Hudson and reviewed by Guido.
>> I wonder why this patch chose to add mapping protocol support to tuples
>> and lists, rather than add a tp\_ slot for extended slicing.
>
> That's long ago... IIRC it was for binary compatibility -- I didn't
> want to add an extra slot to the sq struct because it would require
> recompilation of 3rd party extensions. At the time that was an
> important concern.
>

Perhaps the situation can be fixed now without binary compatibility
concerns. PySequenceMethods is:

typedef struct {
lenfunc sq\_length;
binaryfunc sq\_concat;
ssizeargfunc sq\_repeat;
ssizeargfunc sq\_item;
void \*was\_sq\_slice;
ssizeobjargproc sq\_ass\_item;
void \*was\_sq\_ass\_slice;
objobjproc sq\_contains;

binaryfunc sq\_inplace\_concat;
ssizeargfunc sq\_inplace\_repeat;
} PySequenceMethods;

The slots "was\_sq\_slice" and "was\_sq\_ass\_slice" aren't used any
longer. These can be re-incarnated to accept a slice object, and
sequence objects can be rewritten to use them instead of implementing
the mapping protocol (is there any reason listobject implements the
mapping protocol, other than to gain the ability to use slices for
\_\_getitem\_\_?). Existing 3rd party extensions don't \*need\* to be
recompiled or changed, however. They \*can\* be, if their authors are
interested, of course.