[Python-ideas] Intermediate Summary: Fast sum() for non-numbers

[Sergey]

On Jul 15, 2013 David Mertz wrote:

> It seems to me that in order to make sum() look more attractive,
> Sergey presents ugly versions of alternative ways to (efficiently)
> concatenate sequences.

No, I actually tried to choose the most popular and obvious ones.
Of course there're more. E.g. I tested 6 [1]. Do you think that
people often know *args notation or add infinite lists? ;)

But anyway all of them are just workarounds. Better workarounds,
maybe, but still workarounds, and their existence don't fix sum().
Same as existence of wget or curl does not fix the bug in httplib [2].

> flat = []
> map(flat.extend, list_of_lists)
> Using map() for a side effect is slightly wrong, but this is short,
> readable, and obvious in purpose.

Ehm, you were joking when you called that obvious, right? ;)

> Now I'll take your claim as true that 'sum(list_of_lists)' is
> somehow intuitive to you.  So I can't say it is counter-intuitive
> to ALL humans.

So what? Lot's of things are counter-intuitive in programming
languages, including python. For example, don't you think that
  a = a + b
and
  a += b
should be same, and it's counter-intuitive to have them different.
Yet you can have them different in python.

> But it is counter-intuitive to MANY of us, and for us readers who
> think of "sum" as meaning addition in the mathematical sense, code
> that uses this is difficult to understand.

If it makes no mathematical sense then don't apply math to it. :)
In mathematical sense something like:
  x = x + 1
is completely counter-intuitive. There's no "x" for which that
equation could be true. Yet, this line is obvious to every programmer.

I mean, a function does not have to be intuitive for mathematicians
in order to be a useful tool for programmers. :) And the point is:
they already use it, so we already have a bug, I'm just searching
for the best way to fix it. Having a broken tool on your shelves and
saying "don't take that, it's broken" to everyone every time is not
a solution.

> I will argue that sum()'ing sequences is counter-intuitive for MOST
> humans.  It's certainly counter-intuitive to me, and I've written
> a Python book, taught Python, and taken graduate mathematics
> courses (those experiences may pull in opposite directions though).

Be careful about things like "I've written books, taught Python..."
because someone may catch you on some stupid typo (e.g. a missing *
in chain() call) and ask what are you teaching if you don't know
basics yourself. :)

> I'm not sure it has actually "sailed."  It's very well possible to restrict
> sum()'ing lists or tuples in much the same way strings are excluded (even
> though strings have an .__add__() method).  If special attention were taken
> to *not* work for cases where it shouldn't, we could remove this
> counter-intuitive behavior.

It's actually easier to fix it, than to restrict it. To fix it you
just need to apply a patch [3]. You can do that even for Python2,
since it introduces no behaviour change. But restricting it means
removing a feature, it's a major change that breaks backward
compatibility.

—— 

[1]http://mail.python.org/pipermail/python-ideas/2013-July/022065.html

[2]http://bugs.python.org/issue6838

[3]http://bugs.python.org/file30897/fastsum-special-tuplesandlists.patch