On Mon, 14 Mar 2005 19:16:22 -0500, Tim Peters <[EMAIL PROTECTED]> wrote: > [Eric Nieuwland] > >> Perhaps the second argument should not be optional to emphasise this. > >> After all, there's much more to sum() than numbers. > > [Greg Ewing] > > I think practicality beats purity here. Using it on > > numbers is surely an extremely common case.
[Tim Peters] > I'd personally be delighted if sum() never worked on anything other > than numbers. That makes it easy to understand, easy to document, > easy to remember, obvious at first sight, and straightforward to > implement. Everything a framework isn't, but it's not a bad thing to > have *something* that actually means exactly what it looks like it > says <0.5 wink>. Unfortunately this started when I claimed in my blog that sum() was a replacement for 80% of all reduce() uses. This was countered by someone who pointed out that without a 2nd argument it doesn't work for non-numbers that happen to implement __add__, and I'm not sure he was aware you could make it work *with* a 2nd argument (I know *I* had forgotten all about that :-). I think the conclusion should be that sum() is sufficiently constrained by backwards compatibility to make "fixing" it impossible before 3.0. But in 3.0 I'd like to fix it so that the 2nd argument is only used for empty lists. Alex's use case for a nonzero 2nd argument: total = 0 for lst in sequence_of_lists: total = sum(lst, total) can be just as easily written like this: total = 0 for lst in sequence_of_lists: total += sum(lst) and I think that's actually clearer (since the reader doesn't have to know about the 2nd argument's meaning). -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com