<br><br><div class="gmail_quote">On Sat, Mar 3, 2012 at 10:18, Eli Bendersky <span dir="ltr"><<a href="mailto:eliben@gmail.com">eliben@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sat, Mar 3, 2012 at 19:58, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> On Sat, Mar 3, 2012 at 4:20 AM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
>>> I'd expect slice subscripts to be part of the sequence interface, and<br>
>>> yet they are not. In fact, they are part of the mapping interface. For<br>
>>> example, the list object has its slice get/set methods assigned to a<br>
>>> PyMappingMethods struct. So does a bytes object, and pretty much every<br>
>>> other object that wants to support subscripts.<br>
>><br>
>> It comes from:<br>
>> <a href="http://hg.python.org/cpython/rev/245224d1b8c9" target="_blank">http://hg.python.org/cpython/rev/245224d1b8c9</a><br>
>> <a href="http://bugs.python.org/issue400998" target="_blank">http://bugs.python.org/issue400998</a><br>
>><br>
>> Written by Michael Hudson and reviewed by Guido.<br>
>> I wonder why this patch chose to add mapping protocol support to tuples<br>
>> and lists, rather than add a tp_ slot for extended slicing.<br>
><br>
> That's long ago... IIRC it was for binary compatibility -- I didn't<br>
> want to add an extra slot to the sq struct because it would require<br>
> recompilation of 3rd party extensions. At the time that was an<br>
> important concern.<br>
><br>
<br>
</div>Perhaps the situation can be fixed now without binary compatibility<br>
concerns. PySequenceMethods is:<br>
<br>
typedef struct {<br>
lenfunc sq_length;<br>
binaryfunc sq_concat;<br>
ssizeargfunc sq_repeat;<br>
ssizeargfunc sq_item;<br>
void *was_sq_slice;<br>
ssizeobjargproc sq_ass_item;<br>
void *was_sq_ass_slice;<br>
objobjproc sq_contains;<br>
<br>
binaryfunc sq_inplace_concat;<br>
ssizeargfunc sq_inplace_repeat;<br>
} PySequenceMethods;<br>
<br>
The slots "was_sq_slice" and "was_sq_ass_slice" aren't used any<br>
longer. These can be re-incarnated to accept a slice object, and<br>
sequence objects can be rewritten to use them instead of implementing<br>
the mapping protocol (is there any reason listobject implements the<br>
mapping protocol, other than to gain the ability to use slices for<br>
__getitem__?). Existing 3rd party extensions don't *need* to be<br>
recompiled or changed, however. They *can* be, if their authors are<br>
interested, of course.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>Getting rid of the misleading distinction seems like a much better idea than trying to re-conflate some of the issues.</div><div> </div></div>-- <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!<br>