sum and strings

[Carl Banks]

Rhamphoryncus wrote:
> It's also worth stressing (not in response to your post, but others)
> that sum([[1],[2],[3]], []) is just as bad as attempting to sum
> strings, both conceptually (it's not mathematical addition), and
> performance-wise.  Don't do it. :)

Interesting.  I would have guessed that, internally, sum was
implemented with in-place operations (except for the first operation,
which would have to be non-in-place so that it wouldn't modify a
mutable initial value).  But looking at the source, I see that I would
have guessed wrongly: it does not use in-place operations.  So,
although lists are optimized for growing, sum would end up creating a
new list each iteration anyways.  Thus it does have the same penalty
that strings would have.  Good to know.

Obviously, sum can't check for every possible type that would be
inefficient, but at least it could check for common builtins (str,
list, tuple).  That it only checks for strings suggests to me that this
really is just a case of protecting the unwary.  Concatenating strings
is common enough, and the drawbacks of using sum bad enough, that a
special case was considered justified.  Lists and tuples, though
theoretically they have the same issues as strings, probably don't
justify a special case because they're not as common.


> I believe the prefered method to flatten a list of lists is this:
>
> shallow = []
> for i in deep:
>     shallow.extend(i)
>
> Yes, it's three lines.  It's also very easy to read.  reduce() and
> sum() are not.

sum() is really for numerical uses; people ought to just stick to using
it that way.


Carl Banks