Rationale behind the deprecation of __getslice__?

[Steven Bethard]

Nick Coghlan wrote:
> Steven Bethard wrote:
> 
>> Carl Banks wrote:
>>
>>> Wouldn't it work to have __getslice__ call __getitem__?  And, since
>>> that would be too much of a performance hit, have it check whether its
>>> type is list (or str or tuple), and only call __getitem__ if it is not
>>> (i.e., only for subclasses).  I don't think that would be too bad.
>>>
>>> Subclasses would still be free to override __getslice__, but wouldn't
>>> have to.
>>
>>
>> Yeah, that doesn't seem like it would be too bad.  Probably someone 
>> would have to actually run some benchmarks to see what kind of 
>> performance hit you get...  But it would definitely solve the OP's 
>> problem...
> 
> 
> It might be better handled at construction time - if the class supplied 
> to __new__ is a subclass of the builtin type, swap the __getslice__ 
> implementation for one which delegates to __getitem__.

Yeah, that seems like the minimally invasive solution...  I looked a bit 
at the listobject.c code, but I think the patch for this one is a bit 
over my head...

Steve