A hard exercise to help build the right mental model for Python data.
- Solution: https://memory-graph.com/#codeurl=https%3A%2F%2Fraw.githubusercontent.com%2Fbterwijn%2Fmemory_graph_videos%2Frefs%2Fheads%2Fmain%2Fexercises%2Fexercise26.py&play=
- Explanation: https://github.com/bterwijn/memory_graph?tab=readme-ov-file#python-data-model
The “Solution” link visualizes execution and reveals what’s actually happening using 𝗺𝗲𝗺𝗼𝗿𝘆_𝗴𝗿𝗮𝗽𝗵: https://github.com/bterwijn/memory_graph


The
|and|=operators fordictwere added in 3.9 which was released in 2020, so it’s a relatively recent feature.I like having an operator for set union but I don’t like that
a |= bhas different semantics toa = a|b. This violates the principle of least surprise, since the former is supposed to be a shorthand for the latter.The difference between
a |= banda = a | bis exactly the same as the difference betweena += banda = a + b. Nothing new about that, try:or see: https://fosstodon.org/@bterwijn/116328991093782469
For immutable types there is no difference between
a += banda = a + b, try with a tuple.I feel that things like this lead people to say something along the lines of ‘mutability was a mistake’
I’m only half serious, but this is really surprising without Python background
If you don’t want mutability you have to go to a pure functional language like Haskell, but then you have to copy a big list every time you make a change. There are ways to optimize copying by secretly sharing data behind the scene but you pay a performance price in some way. Then again, Python is slow and has mutability but popular for other reasons.
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 += bdoes and one set to do whata = a + bdoes.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
I think the confusion comes from
a += bbeing equivalent toa = a + bfor immutable types, so some people generalize that incorrectly to mutable types too. Otherwise I think it’s pretty cleara += bmutatesa, anda = a + bfirst computesa + band then reassigns that toaso that its identity changes, just like inc = 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++.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
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.
Yeah, the visualisation is great, that is for sure