[Edu-sig] what is a "variable" in Python?

[David MacQuigg]

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 <litvin at 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.urner at 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 at 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 at 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 at python.org
> https://mail.python.org/mailman/listinfo/edu-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160215/73adc655/attachment-0001.html>