I enjoyed our discussion of post-its versus buckets, or not versus: objects in memory take up space, and so are bucket-like, but look how many labels (post-its) some of them have! I find it useful to have memory take shape as something finite, even when we're enjoying more of it on contemporary devices. Python is biased against making gratuitous copies, or against copying gratuitously, we maybe could say. Memory is respected. L.sort() is "in place" whereas sorted(L) leaves L untouched. This "inplace" idea carries forward as a keyword argument (named parameter) in many cases. I confess, in my own courses, I could do more with deepcopy, explaining what it is and how to do it. I'll get on it. When is it a copy, when a view? is a discussion in pandas as well. Another topic: Another pair of categories I like to tease apart are function versus type, when it comes to what's a callable. range() used to be a function that returned a list. Now it returns an instance of the range type, a sequence. More like dict(), int() and so on. Not like hex(). enumerate() and zip() are likewise calls to classes, triggers to __init__s (birth methods). We're asking for instances. We're calling types. Functions return objects too, so one should not say the difference is whether they return objects. Both do. The difference is instances of a type live on with the methods of that type, whereas a function does not directly bequeath its methods to any "children". Functions are factories of other than instances of themselves, even if they return other functions. What nuances this view is that FunctionType is a type of object, so calling a function is calling a type. However, the way a function responds to being called is like an instance does when its type has a __call__ method defined. === One of my favorite ways to connect classes and functions is to show how a class might "eat" a function such that the function remains callable, and yet the instances may also multiply, in which case the functions compose to create other functions: @Composable # class def F(x): return x + 2 @Composable # class def G(x): return 2 * x H = F * F * F * G * G (H is now a "pipeline" of F(F(F(G(G(x))))) ) More on REPL.it: https://repl.it/@kurner/Composing-Functions (red X warning flag next to lambda expression is bogus, runs fine, Spyder is smarter) Kirby PS: this morning I saw Guido's talk at Stanford on type annotations, which he recently tweeted about [1]. I definitely include mentioning to be on the lookout for such syntax going forward, and not being thrown by it. I emphasize that standard core Python sees annotations more as a type of documentation, with 3rd party hooks understanding them more as directives. [1] https://twitter.com/gvanrossum/status/1003792557652914177 (June 4)