Feature request: sorting a list slice

[Heiko Wundram]

Am Sonntag 21 Mai 2006 18:55 schrieb Raymond Hettinger:
> If the perf gain is small and the use cases are infrequent, the
> addition is likely unwarranted.   There is an entire class of feature
> requests that are more appropriate as recipes than for inclusion in the
> language.

The thing is: having an explicit start/stop argument to reverse() and sort() 
doesn't slow down method call much (it's just one if() whose body is skipped 
when the parameters aren't passed, I'd say that the time that's lost here is 
pretty insignificant, in the order of 10^-6 seconds, on _any_ modern 
machine), and on the other hand warrants huge memory gains (if not 
performance gains by saving a memcpy) when you do need to sort or reverse 
slices of large lists.

I've had use cases of the latter (reversing large parts of even larger lists 
in memory) in several data archiving and evaluation programs I wrote, but I 
can also understand the use case that was made by George for having these 
arguments for sort(), so that groupBy() can be extended easily to work on 
subgroups without requiring slicing.

Anyway: having these "extensions" as a recipe won't work here: the main idea 
is saving the slicing by having sort() and reverse() do the "slicing" 
internally (rather, they just add a constant to the lower and upper bound, 
and the user specifies these constants, the internal functions they call 
already work on slices, and the current listobject.c gives them the whole 
list as the slice by default).

The user can't patch this as an extension on the fly, because it requires 
changes to the underlying listobject.c source. That's why George is asking 
for inclusion of this patch.

I just wrote the patch because I had the time to do so, and I won't battle for 
it's inclusion, but again, I see the use cases clearly, at the very least for 
slice support in list.reverse() and array.reverse() (which the patch also 
implements).

--- Heiko.