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
