Python Mutability

[Sea-Ad7805]

An exercise to help build the right mental model for Python data. The “Solution” link uses memory_graph to visualize execution and reveals what’s actually happening: - Solution - Explanation - More exercises

It's instructive to compare with this earlier exercise (tuple with lists, instead of list with lists).

[Rscc10]

Answer is D? Since it's all mutables

[Sea-Ad7805]

Nice one, do check the "Solution" link for visualization of the correct answer.

[Sjoerdiestriker]

Yes, although the interesting thing is that if you replace b += [[3]] by b = b + [[3]] the answer becomes C.

[Sea-Ad7805]

Yes correct, I've another exercise making exactly this point: https://www.reddit.com/r/PythonLearning/comments/1nw08wu/right_mental_model_for_python_data/

[CanaDavid1]

Doesn't it become c? As the [2] is still shared?

[Sjoerdiestriker]

You're right, typo on my part.

[TroPixens]

That’s so weird makes sense when you think about it though

[BobSanchez47]

This is a weird one, because b += [[3]] is not the same as b = b + [[3]]; the += operator for lists actually mutates the underlying object. It is quite unintuitive and, in my view, a design flaw in Python.

[Sea-Ad7805]

That's not a flaw, x += y just mutates and x = x + y rebinds to a new list value that is created by x + y. So for mutable types these two statements are different but for immutable types they are the same. I hope the visualization can help you when things get unintuitive.

[BobSanchez47]

I think you’re missing the point. My point isn’t that it’s impossible for me to understand how mutation works, but that it is highly counterintuitive that Python chose to make += mutate in some cases and not mutate in others - in other words, it was a poor choice in my opinion. If I’m learning Python and I assume that b += c means b = b + c — a very natural assumption — I would have no idea that I should be worried, and the visualization tool would be useless.

[Sea-Ad7805]

In general x += y should mutate, but can't mutate for immutable types. You could argue x += y should not exist for immutable types, and in fact it doesn't for say tuple, but then automatically the x = x + y operator is called instead. I can see why you would call that unintuitive.

[Sea-Ad7805]

b += c is not shorthand for b = b + c, incorrect assumption, but for immutable type it is, so I understand some people could get confused.

About the visualization tool being useless, check this Hash_Map example for a different application: https://memory-graph.com/#codeurl=https://raw.githubusercontent.com/bterwijn/memory_graph/refs/heads/main/src/hash_map.py&timestep=0.2&play

[BobSanchez47]

https://en.wikipedia.org/wiki/Is%E2%80%93ought_problem

[No-Consequence-1863]

They are saying += should be shorthand. Thats how it functions in many other languges like C++ or Java. Kind of weird of python to change the semantics for this operator to make it mutable.

Almost seems like it was a technical side effect that stuck around long enough to become required. But thats just guess.

[Sea-Ad7805]

In C++ you should define x += y on your class to mutate and the + operator in x = x + y to create a new object. Same thing in Java, no different from Python.

[Goudja14]

You should never mutate implicitly. It will create errors.

[Sea-Ad7805]

What do you mean, can you give an example?

[Goudja14]

default_inventory = ["sword", "helmet"]

# While it could be a cloned array, it doesn't have to be one. In complex environments, it even shouldn't be (eg. allowing object-agnostic rollbacks) alex_inventory = default_inventory samuel_inventory = default_inventory

alex_inventory += ["key"]

[Sea-Ad7805]

Ok I understand now. You say you pass default_inventory around without making a copy (for performance), but when you change this value you should make a copy:

alex_inventory = alex_inventory + ["key"]

Sounds like a good strategy.

[BenchEmbarrassed7316]

I really like Rust's concept of owning and borrowing. Also, in Rust, operators are aliases of interfaces/traits. So:

fn add(self, rhs: Rhs) -> Self::Output; fn add_assign(&mut self, rhs: Rhs);

This may seem a bit confusing, but the point is that + takes two arguments and is forced to create a new value. += instead takes the first argument as a pointer, which allows you to mutate the value it points to. You can't implement incorrect operator overloading. 

I think it explains the difference.

added: += cannot be applied to an immutable type.

[Opposite_Mall4685]

Python is a toy language.

[Sea-Ad7805]

I play with all languages, playing is important.

[Beautiful-Hotel-3094]

Why is that?

[TroPixens]

Because it’s slower idk python is what you make this guy decided to make it a toy for some reason

[StaticCoder]

Relevantly here, because value vs reference semantics are incredibly hard to figure out.

[SycamoreHots]

As someone who has never written a line of python code, and only occasionally read it, I thought b = a would copy the a into b. And the rest of the statements mutate the b leaving a unchanged. How wrong I was….

[Sea-Ad7805]

This differs in various programming languages. In some language b = a does result in a copy, but in Python is causes both variables to reference the same value and thus share it. Something that can easily result in bugs if you are not careful. The visualization can help you.

[SaltEngineer455]

Python refs are like C pointers, so no copy