[Python-Dev] slice subscripts for sequences and mappings (original) (raw)

Thomas Wouters thomas at python.org
Sat Mar 3 21:59:13 CET 2012

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 sqlength; binaryfunc sqconcat; ssizeargfunc sqrepeat; ssizeargfunc sqitem; void *wassqslice; ssizeobjargproc sqassitem; void *wassqassslice; objobjproc sqcontains; binaryfunc sqinplaceconcat; ssizeargfunc sqinplacerepeat; } PySequenceMethods; The slots "wassqslice" and "wassqassslice" 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>

More information about the Python-Dev mailing list