Python is a language that seems to make a lot of sense at first but gets a bit weird when you dig into things. The + operator particularly is a bit funny; I recently came across a case where x+=y was not equivalent to x=x+y... Though I can't figure out what it was now.

> a case where x+=y was not equivalent to x=x+y

This is true for lists in Python. `a = a + b` creates a new list, but `a += b` works in-place:

    >>> a = [1, 2]
    >>> b = a
    >>> a = a + [3]
    >>> print(a, b)
    [1, 2, 3] [1, 2]

    >>> a = [1, 2]
    >>> b = a
    >>> a += [3]
    >>> print(a, b)
    [1, 2, 3] [1, 2, 3]

There are other issues with the `+=`-style operators as well - IMO it was a mistake to have `a += b` be anything other than a shorthand for `a = a + b`.

Agreed, but seems haskell also fails to keep commutativity here tho?

Concatenation is not addition in my opinion

I've often wanted something like bits++bits concatenation to work in the same way for numbers as for strings

> Concatenation is not addition in my opinion

For python, syntactically it is. In a general sense, an operation is what you define it to be. Just my opinion.

You were likely doing something with threads and failed to lock `x`, which I would describe as an issue that should be expected. It doesn't really have to do with `+=` so much as it has to do with being aware of race conditions on variable unprotected by a mutex.

Python's list sum are funny like that.

x+=y is equivalent to x.append(y)

x = x + y creates a new list, then assign it to x (highly inefficient in a loop)

> I recently got bitten by trying to do exactly this, concat strings with sum, and spent a while trying to find out if I was being stupid (

Perhaps not stupid, but ignorant, and not just of the special casing in sum which exist because of a footgun.

sum is basically a readability alternative for functools.reduce for adding numbers, and it's special cased for strings because though it would superficially work for strings otherwise, the performance of repeated string concatenations is pathological in python (as in many garbage-collected languages where it forces many allocations), so a special cases was added which points people to the method to produce exactly the same result without the pathological performance issue.

If you are doing something more complex than numbers with heterogenous data that includes strings in a reduction by the addition operator so that the join you'd use with homogeneous collections of strings isn't what you want (I'm not sure that hypothetical is ever going to happen), use functools.reduce, which for readability you probably should be using in preference to sum() if you aren't doing a mathematical sum anyway.

Like you, I know the O(n^2) bahaviour that would occur with a naive repeated concatenation, and like you I would know how to deal with it. You'd use "".join(...) for the special case it was strings and therefore so would I. This needn't be a footgun of any sort, and don't assume I (or others) are ignorant.