Speedup from switch to +=

Not exactly: most of these frameworks essentially JIT compile the entire operation graph so that it can be executed, and the Python code only touches the data at the endpoints of the full computation. I don't know why the JIT compiler doesn't optimize a = b + a to a += b, but I guess they assumed that the JIT-ed code path would only be used once, so the compiler has to be fast.

I don't think this is an operator overloading thing? It's just that `x = y + x` is equivalent to

    z = y + x
    x = z

Basically, creating an object `z` just to throw it away.

`x += y` just adds y to x directly without any intermediary.

You could write this in any language pretty easily. For example, in Rust:

    let x = "abc".to_string();
    let y = "123".to_string();
    let x = x + &y;

as opposed to the more efficient:

    let mut x = "abc".to_string();
    let y = "123".to_string();
    x.push_str(&y);

It's just using an operation to mutate in place vs an immutable operation.

If python did not have operator overloading it would not be used for numeric programming to the extent it is. Overloading is key to its success in that field.

The problem is thinking `+' and `+=' are the same, they are not and `+' should not be used when `+=' can be used.

This isn't a Python issue, this is a "I'm copying when I don't need to" issue. As I mention elsewhere, you can write this sort of "bug" in almost any language pretty easily (as I demonstrate with Rust).

This isn't a case of "The Python interpreter is bad" it's just that the code is doing what the user asked it to do - create a completely new copy of the data, then overwrite the old copy with it. Immutable operations like this are slow, mutating the value (what += does) is fast.

Granted, a compiled language could recognize that you're doing this, but it also might not - is `+` and `+=` semantically identical such that the compiler can replace one with the other? Maybe? Probably not, if I had to guess. The correct answer is to just use the faster operation, as it is with all language.

I don't know the type of `x`, but I'd suggest another optimization here would be to:

a) Preallocate the buffer rather before mutating it 3x (which is still likely forcing some allocations)

b) Reuse that buffer if it's so important, store it in `self` and clear it before use.

> way more optimization work's gone into the mainstream Javascript runtimes than CPython

Even so, there are absolutely silly things which can hint JS JITs to optimize (or to not deoptimize). Like defining and instantiating a class rather than just creating POJOs with the same values, or assigning NaN instead of null to uninitialized numeric variables/properties. Conditional control flow can deopt, but generally performs better around different function calls than within a single function. Even creating and throwing errors for control flow (which is generally expensive, and terrible for maintenance) can be optimal if your try/catch is the whole body of the function it resides in. And all of those might vary between JITs.