[Python-Dev] slice subscripts for sequences and mappings

[Thomas Wouters]

On Sat, Mar 3, 2012 at 10:18, Eli Bendersky <eliben at gmail.com> wrote:

> On Sat, Mar 3, 2012 at 19:58, Guido van Rossum <guido at python.org> wrote:
> > On Sat, Mar 3, 2012 at 4:20 AM, Antoine Pitrou <solipsis at 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.


Why even have separate tp_as_sequence and tp_as_mapping anymore? That
particular distinction never existed for Python types, so why should it
exist for C types at all? I forget if there was ever a real point to it,
but all it seems to do now is create confusion, what with many sequence
types implementing both, and PyMapping_Check() and PySequence_Check() doing
seemingly random things to come up with somewhat sensible answers. Do note
that the dict type actually implements tp_as_sequence (in order to support
containtment tests) and that PySequence_Check() has to explicitly return 0
for dicts -- which means that it will give the "wrong" answer for another
type that behaves exactly like dicts.

Getting rid of the misleading distinction seems like a much better idea
than trying to re-conflate some of the issues.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120303/a3d53cdb/attachment.html>