"Michael Chermside" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Tim writes: >> I'd personally be delighted if sum() never worked on anything other >> than numbers. > > Guido writes: >> 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. > > Guido, I find myself far more convinced by Tim's suggestion than > yours.
I am leaning in that direction too. >This all started with your claim that sum() was a replacement > for most reduce() uses. To me, the proper general replacement for the doubly broken builtin reduce would be a properly-defined functional.reduce (a subject for another post), not a bloated sum ;-) > We all agree that it works fine for summing up > numbers. We all agree it DOESN'T work for any case where the operator > isn't __add__. However, __add__ can be defined to mean anything. I'd hate to see people choosing '+' as an operator symbol merely to get reduction disguised as summation. [snip] > What I think is MORE important is that sum() have predictable behavior > in the degenerate cases. And by "predictable", I mean predictable by > a newbie user or one someone who hasn't looked at the docs for sum() > for the past year and mostly remembers what it does only because the > name is so blatantly obvious. Nick's very unmemorable a,b,c,d rules shows the complications that reduction-disguised-as-summation can lead to. Terry J. Reedy _______________________________________________ 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