The short answer is that I agree with you. In fact, the link you shared is an example of my favourite incorrect mental model, which even prompted me to post this rant https://learnpython.wordpress.com/2015/05/21/notes-on-teaching-python-mental-models/ some months ago.
TL;DR - "in Python 'variables' are post-its, not buckets". (to use one of my own homely metaphors) Cheers, Naomi On 15 February 2016 at 13:02, kirby urner <kirby.ur...@gmail.com> wrote: > > What do educators think about this discussion of variables in Python? > > http://www.python-course.eu/variables.php > > I find the "variable versus identifier" discussion, with repeated > references to C / C++, to be somewhat on the confusing side. > > My view is "variable as container" makes sense if you're talking about the > object itself, on the heap, e.g. the list, dict or tuple or whatever. > > I might write the word "Object" with a big "O" and say that represents "a > container in memory" (contains data and methods e.g. datetime.datetime > objects). > > But then I'd say said object is "variable" only if it's mutable i.e. it > could be a constant (immutable) in contrast. Strings and integers are not > "variables" as you can't do anything to mutate them. Lists are variables, > strings are not. > > Names, on the other hand, are like postits or luggage tags, more like > labels for objects, and we can pull a postit (like X) from an object (like > 'A') and stick it on another object (say 3) instead. > > This is *not* a matter of a variable changing i.e. > > X = 'A' > X = 3 > > has nothing to do with "changing the content of a container" (as if 3 had > to fit into the same piece of memory as the 'A' did) but is rather about > slapping the name 'X' onto two different objects in quick succession. > Identifiers don't care what they stick to, as long as they're objects. > > Objects always have type. > > Names are just names: they name things with type, i.e. objects. > > It's not that mysterious -- but the "container" metaphor gets in the way > when you go: > > >>> A = [1,2,3] > >>> B = A > >>> B[-1]=4 > >>> A[2] > 4 > > and then maybe think A should be pictured as a container with [1,2,3] > inside it. So does B have [1,2,3] inside it too, meaning it's own copy? > Of course not, but two "containers" cannot logically "contain" the same > object which is why there's cognitive stress. The "container" metaphor is > obstructive. > > B and A are simply two postits, two tags, affixed to the same object, the > list on the heap, no big deal. > > You can call that object a "variable" if you like, but why not just call > it a "mutable object" instead? > > On the other hand, A and B are just names in the namespace. We use them > to talk to / remotely control said objects, not just name them. Names > don't have type and we don't name names, we name objects. > > A name is a lot like a TV remote, with lots of buttons (dot notation > activated, lots of little callables). An object is a lot like the TV. > > More than one remote controlling the same TV is OK in Python. > > There is no "container" in this picture unless you want to say the TV is a > container (an object), in which case I'd agree. Saying the remote > "contains" the TV is not helpful and just gets in the way the second you > have two remotes for the same object. > > Kirby > > > > _______________________________________________ > Edu-sig mailing list > Edu-sig@python.org > https://mail.python.org/mailman/listinfo/edu-sig > > -- Naomi Ceder https://plus.google.com/u/0/111396744045017339164/about
_______________________________________________ Edu-sig mailing list Edu-sig@python.org https://mail.python.org/mailman/listinfo/edu-sig
