Thomas Wouters wrote:
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,
I imagine the original motivation was to provide a fast
On Sat, 3 Mar 2012 18:20:22 -0800
Thomas Wouters wrote:
>
> I'm not sure how the ABCs, which are abstract declarations of semantics,
> tie into this specific implementation detail. ABCs work just as well for
> Python types as for C types, and Python types don't have this distinction.
> The distin
On Sun, Mar 4, 2012 at 12:24 PM, Thomas Wouters wrote:
> (Let's not forget about tp_as_sequence.sq_concat, tp_as_number.nb_add,
> tp_as_sequence.sq_repeat and tp_as_number.nb_mul either.)
Indeed, let's not forget about those, which are a compatibility
problem in and of themselves: http://bugs.pyt
>> Thomas Wouters, 03.03.2012 21:59:
>> > 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
On Sat, Mar 3, 2012 at 13:12, Stefan Behnel wrote:
> Thomas Wouters, 03.03.2012 21:59:
> > 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 r
On Sat, Mar 3, 2012 at 13:02, Antoine Pitrou wrote:
> On Sat, 3 Mar 2012 12:59:13 -0800
> Thomas Wouters wrote:
> >
> > 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?
Thomas Wouters, 03.03.2012 21:59:
> 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 confu
On Sat, 3 Mar 2012 12:59:13 -0800
Thomas Wouters wrote:
>
> 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
On Sat, Mar 3, 2012 at 10:18, Eli Bendersky wrote:
> On Sat, Mar 3, 2012 at 19:58, Guido van Rossum wrote:
> > On Sat, Mar 3, 2012 at 4:20 AM, Antoine Pitrou
> wrote:
> >>> I'd expect slice subscripts to be part of the sequence interface, and
> >>> yet they are not. In fact, they are part of th
On Sat, Mar 3, 2012 at 19:58, Guido van Rossum wrote:
> On Sat, Mar 3, 2012 at 4:20 AM, Antoine Pitrou 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 s
On Sat, Mar 3, 2012 at 4:20 AM, Antoine Pitrou 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 struc
Le samedi 03 mars 2012 à 14:41 +0200, Eli Bendersky a écrit :
> >> 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
> >> PyMappi
>> 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
>> oth
Hi,
> 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
> ot
On Sat, Mar 3, 2012 at 11:24, Stefan Behnel wrote:
> Eli Bendersky, 03.03.2012 09:36:
>> I find a strange discrepancy in Python with regards to slice
>> subscripting of objects, at the C API level. I mean things like
>> obj[start:end:step].
>>
>> I'd expect slice subscripts to be part of the seque
Eli Bendersky, 03.03.2012 09:36:
> I find a strange discrepancy in Python with regards to slice
> subscripting of objects, at the C API level. I mean things like
> obj[start:end:step].
>
> I'd expect slice subscripts to be part of the sequence interface, and
> yet they are not. In fact, they are p
> This doesn't align well with the documentation, in at least two places.
>
Another place is in http://docs.python.org/dev/reference/datamodel.html:
"
object.__getitem__(self, key)
Called to implement evaluation of self[key]. For sequence types,
the accepted keys should be integers and slic
Hello,
I find a strange discrepancy in Python with regards to slice
subscripting of objects, at the C API level. I mean things like
obj[start:end:step].
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
exa
18 matches
Mail list logo
