On Tue, 15 Mar 2005 22:21:07 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > 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. > > Two questions about this: > > 1. When omitting the second argument, would supplying an empty list return 0, > None or raise an exception?
Good question... > The last seems most reasonable, as otherwise the function is guessing about > what > the programmer wants. OTOH 0 is more compatible and None is a strong candidate too... > 2. How would the initial value that forms the basis of summation be built for > non-empty sequences? Here's you're way off. There's never any use of "+=", so never any need to create a new object. The algorithm I had in mind was: - if empty, return 2nd arg - if one item, return that - if more than one item (A, B, C, ...) return (...((A + B) + C) + ...) But I'm not so sure now. Thinking ahead to generic types, I'd like the full signature to be: def sum(seq: sequence[T], initial: T = 0) -> T. and that's exactly what it is today. Conclusion: sum() is perfect after all! -- --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
