Yes I understand your point, but I'm trying to reach out so people are aware and can use it in Python education. I feel it can really help beginners understand tricky concepts with ease, bit it's hard to reach a bigger audience these days. Sorry for the repetition, I'll guess I should cut back a bit.

It's definitely not the same. Similarly for a class you can define the __add__ dunder method for a + b and separately the __iadd__ dunder method for a += b. The first creates a new object, the latter changes/mutates the existing object a. For immutable types it is the same though.

The "Solution" link gives the solution to the exercise, the "Explanation" link explains the Python data model concepts behind the exercise. If some parts are hard to understand let me know.

__add__ is called with + and __iadd__ is called with +=, and there is a difference: https://www.reddit.com/r/PythonLearning/comments/1nw08wu/right_mental_model_for_python_data/

Thanks, glad it helps you.

Yes, that is a surprise to many, in other languages 'x+=y' and 'x=x+y' are the same.

I like to use this example with my students: https://github.com/bterwijn/memory_graph#lazy-evaluation

Copying a list with a million elements every time you make a small change is not fun. Sure, you can optimize a bit behind the scenes, but that still gives a lot of overhead.

Glad you like it. Sketching by hand should remain standard practice, but for beginners that might be difficult. First they need to learn the right mental model to think about Python data, and I hope memory_graph can help with that.

You can just write your code and then press "Get URL" to get the link: https://memory-graph.com/#code=def+fun%28a+%3D+%5B%5D%29%3A%0A++++a+%2B%3D+%5B1%5D%0A++++return+a%0A%0Afun%28%29%0Aprint%28fun%28%29%29+%23+%5B1%2C+1%5D

DuckDuckGo problem, thanks for reporting.

Thanks for reporting, should be fixed now.

Thanks for your feedback, much appriciated.

I agree that an exercise14.rst would be nice, but to save time I've let the code speak for itself now together with the visualizaion. I'll probably revisit and better document the exercises later.

At the Explanation link I try to give a general explanation about Pyrhon mutability (and copy later on), I agree some readers might find it hard to relate that to a specific exercise, but I don't want to write a specific explanation for each exercise.

Actually running the code? I got to the stage where only AI can help me understand anything ;-)

Nice one, see the "Solution" link for correct answer.

Sure, but a lot of people incorrectly think the __eq__ and __hash__ are defined based on value not identity, as they are for many other types say float, str, or tuple. But for a class the default __eq__ method is x is y instead of x == y and also __hash__ is based on identity.

Others assume that if you don't define __hash__ for a class, that it doesn't exists (like for list, set, or dict) so that a "TypeError: unhashable type: 'Value'" exception is raised.

I thought it was an interesting exercise to share, but maybe too simple for this audience, or people are just not aware of the basic steps that happen when adding and searching values in a set/dict. Try the same with type int:

v1 = 1001
v2 = 1002
myset = {v1}
print(v1 in myset, end=' ')
v2 = 1001
print(v2 in myset, end=' ')
v1 = 1002
print(v1 in myset, end=' ')

and you see a different output. To do the same with the Value class add methods:

def __eq__(self, other):
    return self.value == other.value

def __hash__(self):
    return hash(self.value)

Incorrect sorry, check the "Solution" link for the correct answer.

The whole point is to practice Python Data Model concepts, it's not a best-way-to-code example, so feel free to hate.

Appreciated!

Thanks, I'm pretty stoked about it myself.

Thanks for adding. The link I posted should give people a quick animation to directly see what is possible instead of having to read through things first. That GitHub repo link is also on hat page. But you are right that some would probably want to start with the repo, thanks for feedback.