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

[kirby urner]

http://www2.engr.arizona.edu/~edatools/ece175/Lecture/python-variables.htm

seems completely unobjectionable (forgive pun).

The notion of a Python variable inherits from lamba x: x + 1 i.e. we don't
specify the x and so map(lambda x: x + 1, [1, 2.0, Decimal(3)]) makes sense
with all these differently typed inputs.

In [8]: list(map(lambda x: x + 1, [1, 2.0, Decimal(3)]))
Out[8]: [2, 3.0, Decimal('4')]

I'm using I-Python inside Spyder these days when I project.

But what's actually going on here is well-expressed by the word "binding".
We say a name is "bound to" an object which again does not intuitively
suggest "put inside of".

Some of us teach Python without inducing thoughts of little boxes (buckets)
whereas others of us want to use that.  There's diversity in our midst and
this is not a cause for either alarm or skulking.

I'm glad edu-sig is getting used for its stated purpose in any case.  You
can bet I'm pointing a lot of people to this thread as I emphasize the
importance of mental models.

I take it further than Naomi with my TV remote analogy.

That's an analogy that works especially well with the Netflix couch potato
crowd, some of whom show up at code school anxious to work out.  In
cultures where TV remotes are not familiar objects, I would hesitate to
make such abundant use of it in my lectures.

Kirby



On Mon, Feb 15, 2016 at 2:26 PM, David MacQuigg <macquigg at ece.arizona.edu>
wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/219d4c3e/attachment.html>