Bill Janssen wrote:
George Sakkis <george.sakkis@gmail.com> wrote:
On Sat, Dec 5, 2009 at 8:10 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
George Sakkis writes:
On Sat, Dec 5, 2009 at 6:45 PM, Andre Engels <andreengels@gmail.com> wrote:
In your proposed implementation, sum([]) would be undefined.
Which would make it consistent with min/max.
There's no justification for trying to make 'min' and 'sum' consistent. The sum of an empty list of numbers is a well-defined *number*, namely 0, but the max of an empty list of numbers is a well-defined *non-number*, namely "minus infinity".
The real question is "what harm is done by preferring the (well-defined) sum of an empty list of numbers over the (well-defined) empty sums of lists and/or strings?" Then, if there is any harm, "can the situation be improved by having no useful default for empty lists of any type?" Finally, "is it worth breaking existing code to ensure equal treatment of different types?"
My guess is that the answers are "very little", "hardly at all", and "emphatically no."<wink> Agreed that there is little harm in preferring numbers over other types when it comes to empty sequences, but the more important question is "should the start argument be used even if the sequence is *not* empty?". The OP doesn't think so and I agree.
Or perhaps, the *default* start value should not be used if it doesn't match in type the first element of a non-empty sequence. An explicitly specified start value should still be used even if the sequence is *not* empty.
Currently if start is None then the result is None if the sequence is empty, but raises a TypeError otherwise. Would it break any existing code if was this instead: sum(sequence, start=0) If start is None then it's omitted from the summation, unless the sequence is empty, in which case the result is None.