Seems like the difference is merely a matter of how we define the word "variable". Is it the label, or is it the object? I've always thought of it as being the label. Here is how I explained Python "variables" to engineering students (who were taking a class on C). Maybe I should have used the word "labels" instead. http://www2.engr.arizona.edu/~edatools/ece175/Lecture/python-variables.htm
This discussion reminds me of the controversy over whether Python functions are call-by-value or call-by-reference. http://www2.engr.arizona.edu/~edatools/ece175/Lecture/calling_methods.py I like Bruce Eckel's sidestep on this issue. http://www2.engr.arizona.edu/~edatools/ece175/Lecture/QnA.txt "In the end, it isn't that important. What is important is that you understand that passing a reference allows the caller's object to be changed unexpectedly." David MacQuigg, PhD On Mon, Feb 15, 2016 at 1:19 PM, Litvin <lit...@skylit.com> wrote: > Sorry, I don't agree. Thinking of variables as named containers is not an > "incorrect mental model" but a useful metaphor for teaching programming to > novices. In my mental model, variable is called a "variable" because it > can hold different values at different times. This has nothing to do with > immutability. Immutability applies to objects, not variables; an immutable > object cannot change its state after it has been created, regardless where > it is stored. A tuple is immutable but a variable can hold different > tuples. Immutability is a more difficult, OOP concept, and the discussion > of immutability does not belong with an introductory topic of variables. > > Putting postits on, say, numbers is hard to swallow. After all, = is > called an assignment operator, not a naming operator. Novices have enough > trouble remembering what is assigned to whom. The only difference between > Python and a strongly typed language is that Python's "containers" are > flexible: they can hold values of different types at different times. So > in Python, a container does not have a type, only the value that it > currently holds. This is not too hard for students to grasp. > > Kirby's link has a confused discussion of identifiers and in general may > be not the best way of introducing variables, but one confusing page > doesn't warrant wholesale revision of concepts that have been successfully > taught for decades and apply to other languages that a student might know > or will encounter in the future. Just my 2c. > > Gary Litvin > www.skylit.com > > At 02:15 PM 2/15/2016, you wrote: > > 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 > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2016.0.7442 / Virus Database: 4530/11630 - Release Date: 02/15/16 > > > _______________________________________________ > Edu-sig mailing list > Edu-sig@python.org > https://mail.python.org/mailman/listinfo/edu-sig > >
_______________________________________________ Edu-sig mailing list Edu-sig@python.org https://mail.python.org/mailman/listinfo/edu-sig