Thanks, but I also give a solution link, so people can already cheat if they really want too.
Thanks a lot, I hope it can bring much value for you.
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.
Great, I hope it can bring much value for your teaching.
If you are interested see the dictionary docs (https://docs.python.org/3/builtins/stdtypes.html#dict):
d |= otherUpdate the dictionarydwith keys and values fromother, which may be either a mapping or an iterable of key/value pairs. The values ofothertake priority whendandothershare keys. Added in version 3.9.
Pick your answer and check the Solution link.
There is one important difference between a |= b and a = a | b, that is one part that makes this exercise difficult. See the dictionary docs (https://docs.python.org/3/builtins/stdtypes.html#dict):
d |= otherUpdate the dictionarydwith keys and values fromother, which may be either a mapping or an iterable of key/value pairs. The values ofothertake priority whendandothershare keys. Added in version 3.9.
Pick your answer and check the Solution link.
The zen of Python lies unless you're Dutch. I'm Dutch and when I look out of my office I see the CWI where Guido wrote the original Python versions back in the day, see "Python the documentory" on YouTube.
I've built a nice visualizer for internalizing what is going on under the hood, I hope that can help people.
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++.
Thanks, maybe I should have added that possible answer instead of 'D', adding one more feels too many.
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.
Thanks, I'm pretty happy with it myself.
The difference between a |= b and a = a | b is exactly the same as the difference between a += b and a = a + b. Nothing new about that, try:
a = [1]
b = a
b += [2]
b.append(3)
b = b + [4]
b.append(5)
print(a)
or see: https://fosstodon.org/@bterwijn/116328991093782469
For immutable types there is no difference between a += b and a = a + b, try with a tuple.
A hard exercise to help build the right mental model for Python data.
The “Solution” link visualizes execution and reveals what’s actually happening using 𝗺𝗲𝗺𝗼𝗿𝘆_𝗴𝗿𝗮𝗽𝗵: https://github.com/bterwijn/memory_graph
In last week’s post we showed that a Python for-loop works through the Iterator Protocol.
This same protocol also enables values to be produced lazily.
In this new Lazy Evalution Example we show one sink reading values from five different sources:
The same for-loop consumes all five sources. The eager sources produce all values before the sink starts consuming them. In the lazy sources producer and consumer take turns:
Each value is produced only when the for-loop requests it.
Generator functions and generator expressions are concise, readable ways to create lazy iterables. The final source makes their underlying mechanism explicit:
iter() obtains an iterator.next() requests the next value.StopIteration signals that no values remain.This clearly shows that generators achieve lazy iteration by implementing Python’s Iterator Protocol.
Yesterday my exercise got downvoted, probably because its point was unclear. I'd like to try again with this reworked exercise. Hope you'll like this one better.
__eq__() and __hash__() methods by default (inherited from the object class); with them, all objects compare unequal (except with themselves) and x.__hash__() returns an appropriate value such that x == y implies both that x is y and hash(x) == hash(y).”#Python #memory_graph #Equality #Hashing
An exercise to help build the right mental model for Python data.
#Python #memory_graph #Equality #Hashing
Recursion becomes much easier once students have the right mental model. Visualization will help get them there.
Take the Tower of Hanoi problem. The recursive solution is beautifully short, to move n disks we:
But when students try to implement recursion, they often get stuck, and adding debug prints only adds to the confusion. That is where visualization can help to bring the right mental model. Here is the Tower of Hanoi problem solved recursively, visualized with 𝗶𝗻𝘃𝗼𝗰𝗮𝘁𝗶𝗼𝗻_𝘁𝗿𝗲𝗲: https://www.invocation-tree.com/#codeurl=https%3A%2F%2Fraw.githubusercontent.com%2Fbterwijn%2Fmemory_graph_examples%2Frefs%2Fheads%2Fmain%2Ftowers_of_hanoi.py×tep=0.5&play=
Instead of thinking about “a function calling itself again and again” students can now see the depth-first execution of a tree of subproblems showing the divide-and-conquer strategy in action. Once a student can think in terms of a tree of subproblems, recursion becomes much easier to understand, explain, and debug.
#Python #invocation_tree #Recursion
The difference in Python OOP between:
visually explained using 𝗺𝗲𝗺𝗼𝗿𝘆_𝗴𝗿𝗮𝗽𝗵:
An exercise to help build the right mental model for Python data.
The “Solution” link visualizes execution and reveals what’s actually happening using 𝗺𝗲𝗺𝗼𝗿𝘆_𝗴𝗿𝗮𝗽𝗵: https://github.com/bterwijn/memory_graph
Data structures like Trie can in Python be easier understood and debugged after visualization using the memory_graph package.
A Trie is a tree of dictionaries and can be used for things like word completion.
Data structures become much easier to understand when students can see the structure of their data visualized using memory_graph. A data structure is no longer an abstract idea but concrete, clear and debuggable. Here’s a live demo of a Linear Linked List: https://memory-graph.com/#codeurl=https%3A%2F%2Fraw.githubusercontent.com%2Fbterwijn%2Fmemory_graph%2Frefs%2Fheads%2Fmain%2Fsrc%2Flinked_list_lin.py&breakpoints=27&continues=1×tep=0.2&play=
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:
Understanding and debugging Python data structures gets easier with memory_graph visualization. Here's a Multiway Tree example. A Multiway Tree is similar to a Binary Tree but has an arbitrary number of children making the tree less deep and more efficient.
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:
