On Sat, Mar 3, 2012 at 10:18, Eli Bendersky <eli...@gmail.com> wrote:
> On Sat, Mar 3, 2012 at 19:58, Guido van Rossum <gu...@python.org> wrote: > > On Sat, Mar 3, 2012 at 4:20 AM, Antoine Pitrou <solip...@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 <tho...@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
