I'm not sure whether this is a bug or a feature request, but it seems as though the following should produce the same result:

In [1]: 'a' + 'b' + 'c'
Out[1]: 'abc'

In [2]: sum(('a', 'b', 'c'))
TypeError Traceback (most recent call last)
in
----> 1 sum(('a', 'b', 'c'))

TypeError: unsupported operand type(s) for +: 'int' and 'str'

The error message is confusing (there is no integer).

This happens because the default value for the start argument is zero , hence the first operation is `0 + 'a'`

also worth noting, the start argument is type checked instead. Maybe we could apply the same checks to the items of the iterable?

python3 -c "print(sum(('a', 'b', 'c'), start='d'))"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: sum() can't sum strings [use ''.join(seq) instead]


see https://github.com/python/cpython/blob/c96d00e88ead8f99bb6aa1357928ac4545d9287c/Python/bltinmodule.c#L2310

As Marco says, the exception message is because the default value for start is 0, and you can't concatenate strings to the integer 0.

You get the same error if you try to concatenate lists:

    py> sum([[], []])
    TypeError: unsupported operand type(s) for +: 'int' and 'list'


However, even if you provide a default of the empty string, "", sum will still reject string arguments. This is intentional, as repeatedly concatenating strings may be extremely inefficient and slow, depending on the specific circumstances.


The default of 0 is documented, as is the intention that sum be used only for numeric addition. See `help(sum)` or the docs on the website.

Marco, sum should be as fast as possible, so we don't want to type check every single element. But if it is easy enough, it might be worth checking the first element, and if it fails, report:

    cannot add 'type' to start value

where 'type' is the type of the first element. If that is str, then concatenate

    (use ''.join(iterable) instead)

to the error message.

I was thinking to just clarify a bit the error message that results from Py_NumberAdd. This won't make it slower in the "hot" path

doing something like (not compile tested, sorry)

--- a/Python/bltinmodule.c
+++ b/Python/bltinmodule.c
@@ -2451,8 +2451,13 @@ builtin_sum_impl(PyObject *module, PyObject *iterable, PyObject *start)
         Py_DECREF(result);
         Py_DECREF(item);
         result = temp;
-        if (result == NULL)
+        if (result == NULL) {
+         if (PyUnicode_Check(item) || PyBytes_Check(item) || PyByteArray_Check(item))
+             PyErr_SetString(PyExc_TypeError,
+                   "sum() can't sum bytes, strings or byte-arrays [use .join(seq) instead]");
+           }
             break;
+       }
     }
     Py_DECREF(iter);
     return result;

I'd forgotten about ''.join; this is a good solution.  I withdraw my
comment.

On Mon, Sep 7, 2020 at 3:25 PM Steven D'Aprano <report@bugs.python.org>
wrote:

>
> Steven D'Aprano <steve+python@pearwood.info> added the comment:
>
> Marco, sum should be as fast as possible, so we don't want to type check
> every single element. But if it is easy enough, it might be worth checking
> the first element, and if it fails, report:
>
>     cannot add 'type' to start value
>
> where 'type' is the type of the first element. If that is str, then
> concatenate
>
>     (use ''.join(iterable) instead)
>
> to the error message.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue41740>
> _______________________________________
>

The fact that you've forgotten about it is exactly why sum tries to educate you (despite Python being "the language of consenting adults" in most other aspects). The problem (why it doesn't do a good job in that aspect) is that people usually expect sum to act like a 2-arg form of functools.reduce, while in fact it acts like a 3-arg form, with 0 as the initializer.

I doubt that Python will change regarding that, but you can sharpen your intuition by asking yourself: what do you expect sum([]) to be? If 0, then you're inconsistent. :-)