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. -- http://mail.python.org/mailman/listinfo/python-list
