"Michael Chermside" <mcherm at mcherm.com> wrote in message news:20050315051257.a9dv3dxzbhk4sswo at mcherm.com... > 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4