I don't think mutability is wrong as a concept, albeit I enjoyed learning and toying with Haskell, but I really think these functions in Python should have been two sets of operations, one set to do what a += b does and one set to do what a = a + b does.

I've been doing C++ for quite some time and amount of implicit things that happen magically and not everyone get them right and this leads to bugs and confusion had really grown on me with time, and I feel like this is the same pattern here, where we get implicit magic instead of being clear with intentions and results

[–] bterwijn@programming.dev 3 points 6 days ago* (last edited 6 days ago) (1 children)

I think the confusion comes from a += b being equivalent to a = a + b for immutable types, so some people generalize that incorrectly to mutable types too. Otherwise I think it's pretty clear a += b mutates a, and a = a + b first computes a + b and then reassigns that to a so that its identity changes, just like in c = a + b.

If you implement these operations in a class you have to implement each dunder, __iadd__(self, other) and __add__(self, other) separately, same thing in C++.

[–] sukhmel@programming.dev 1 points 6 days ago (1 children)

It is only clear if you already have a model of how labels work in Python and while it is understandable to me now, I wouldn't say this is anything I would expect

Then again, shadowing variables is allowed in other languages and is also a source of confusion and mistakes at times

[–] bterwijn@programming.dev 1 points 6 days ago (1 children)

The point of the visualization at the Solution link is precisely to help people get the right model of how labels and the data model in general works in Python. See the Explanation link for more details.

[–] sukhmel@programming.dev 1 points 6 days ago (1 children)

Yeah, the visualisation is great, that is for sure

[–] bterwijn@programming.dev 1 points 6 days ago

Thanks a lot, I hope it can bring much value for you.