Rationale behind the deprecation of __getslice__?
steven.bethard at gmail.com
Fri Dec 10 22:42:16 CET 2004
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
> 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...
More information about the Python-list