Glenn Linderman writes:
On 8/10/2014 1:24 AM, Stephen J. Turnbull wrote:
Actually ... if I were a fan of the "".join() idiom, I'd seriously propose 0.sum(numeric_iterable) as the RightThang{tm]. Then we could deprecate "".join(string_iterable) in favor of "".sum(string_iterable) (with the same efficient semantics).
Actually, there is no need to wait for 0.sum() to propose "".sum... but it is only a spelling change, so no real benefit.
IMO it's worse than merely a spelling change, because (1) "join" is a more evocative term for concatenating strings than "sum" and (2) I don't know of any other sums that allow "glue". I'm overall -1 on trying to change the current situation (except for adding a join() builtin or str.join class method). We could probably fix everything in a static-typed language (because that would allow picking an initial object of the appropriate type), but without that we need to pick a default of some particular type, and 0 makes the most sense. I can understand the desire of people who want to use the same syntax for summing an iterable of numbers and for concatenating an iterable of strings, but to me they're really not even formally the same in practical use. I'm very sympathetic to Steven's explanation that "we wouldn't be having this discussion if we used a different operator for string concatenation". Although that's not the whole story: in practice even numerical sums get split into multiple functions because floating point addition isn't associative, and so needs careful treatment to preserve accuracy. At that point I'm strongly +1 on abandoning attempts to "rationalize" summation. I'm not sure how I'd feel about raising an exception if you try to sum any iterable containing misbehaved types like float. But not only would that be a Python 4 effort due to backward incompatibility, but it sorta contradicts the main argument of proponents ("any type implementing __add__ should be sum()-able").