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 -- http://mail.python.org/mailman/listinfo/python-list