On Mon, Feb 15, 2016 at 8:48 PM, Andrew Harrington <ahar...@luc.edu> wrote:
> I agree with Gary that mutability is a property of objects, not of
> variables.
>
I think everyone who has put in two cents so far, including me, agrees with
this point.
The only rewording I might suggest is "mutability is a property of objects,
not names" (saying "names" instead of "variables") as I think it's fine to
introduce Python to newbies without using the word "variable" (certainly
not to mean "container" if used).
"Names and objects" are sufficient to start with. Occam's Razor and all
that.
Some names aren't bound until run time, as happens when list(map(lambda
x,y: x+y, ["T"], ["ED"])) actually executes:
In[3]: list(map(lambda x,y: x+y, ["T"], ["ED"]))
Out[3]: ['TED']
Names often get bound to objects without any need of the assignment
operator.
def F():
<function body>
does name binding, of a name (F) to some callable object.
The for loop is another example, of binding without need of the assignment
operator (=):
for x in H:
body of loop
shows how the same label, x, may be applied to items in succession. This x
doesn't "contain" objects in H one by one, it merely tags them, and thereby
gives code in the loop body an opportunity for controlling them.
The assignment operator is a binding operator, in that it binds names to
objects. Names do not "swallow" objects and take them prisoner. Names are
not cells. Names have no internals.
But then dot notation is often applied to them.
aTV.on() controls some instance on the heap.
aTV is a name with no TV "inside" it. aTV is remote from the TV, yet bound
to it.
Objects themselves are aptly modeled as containers, sure, and have both
methods and data (typically) internally. Objects are what's complex.
Names are simple (no internals).
An object is typically mutable but of course not always -- an important
distinction that should be front and center, once "naming" ("assigning") is
understood.
> An object has methods. A name does not - it can refer to an object with a
> particular method.
>
An object (noun) has these various verbs that we might call (__call__), but
we do so using Python names (identifiers) most typically.
3 .__add__(2) makes sense, i.e. an int or string literal or "naked object"
may be the subject of a method (e.g. "ABC".lower()).
Usually though, we'd need a name for our objects, having no "naked"
(syntactically primitive) form. The name anchors a surrounding namespace,
of the methods and attributes therewith associated.
A name is inside a namespace, and likewise comprises a namespace (with dot
methods and dot attributes). The name remains distinct from the object
itself in memory (on the heap).
The TV remote idea is: if I aim a remote at a TV, it has __on__ and
__off__ methods (so to speak).
But if I "aim" a remote at (i.e. "bind" a remote to) another object type,
then the "buttons" (the API, i.e. the methods) will be different. Only
some types have __on__ and __off__.
We all agree it's on the TV itself that channel changing happens (it's the
TV itself that's mutable -- back to where we started, agreeing above).
Going:
>>> myTV = TV()
>>> myTV.change(6)
is making a mutable object's state mutate.
myTV is not the object itself, it's a name for some object (and not a
container of it either -- an image we don't need).
> I do not get the variable and remote buttons analogy at all. The
> importance of a variable naming a memory *location* with a reference is
> that clearly there can be only one reference at that memory location at a
> time.
>
But once you have that name (what some call a "variable"), there's now so
much more you can do, beyond simply naming.
If S names a string, you can now S.upper() it, and if it's an int, you can
S.__add__ it to something else.
The name (remote) "sprouts buttons" (like off and on) in accordance with
what type it aims at (binds to).
The name has its dot methods and dot attributes, useful for changing that
stuff in memory which actually does the work.
> There is nothing saying with the English word "label" that two different
> objects/places could not have the same naming label slapped on them, so
> relying too heavily on easy English analogies is tricky.
>
How do I take the very same physical post-it, this very one, and affix it
to two different objects at the same time?
How would you draw that? It seems grammatically challenging.
I suppose one could sort of half-affix it to two different objects and the
same time. A luggage tag could loop through two suitcase handles. OK, you
got me there: the English is ambiguous.
However: how do five "containers" (known as "variables" in some
narratives) all "contain" the "same" object, which they may be proved to
do, using id(A), id(B), id(C) and so on? A,B,C,D,E all reference the very
same object. What's the picture?
How does it help to say these five names of the same thing are "containers"
of that thing? Why do "buckets" make more sense that "post-its"?
The object itself is a container (like a bucket), sure, in that it likely
has / contains attributes (data), and is either mutable or not. So I'm
willing to say the object is variable, in the sense of mutable, but that
just grates on the ears of those who want to say "variable" to mean "Python
name".
Names of these objects by be known as "variables" but they are not
containers and they only "vary" in the sense that names, like post-its, may
be affixed to any object of any type. Integer or steam engine, it won't
matter.
So lets put to rest the idea that A,B,C... all "contain" the same object.
There's no mental picture that's not messy in that case.
>
> In my Hands-on Python Tutorial <http://anh.cs.luc.edu/python/hands-on/3.1>
> I say all data has a type, and I start with immutable objects types. I say
> initially that a variable is a name used to refer to a piece of data.
>
No problem with any of that. Or just say we use names to refer to data
(objects).
Who cares about "variables"? As opposed to what, "constants"? Do we call
a luggage tag a "variable" just because it tags any suitcase? I suppose we
could.
> Much later I get to mutable objects, and then the idea of a reference to
> an object is key to understanding.
>
Sounds good too.
remote = TV() # give me a way to control a TV instance
remote.on() # now I'm controlling it, using the name (remote)
remote.change_channel(6) # controlling it more (it being some thing on the
heap)
The remote is controlling something on the heap that may have many names.
When it has no names, it gets garbage-collected.
> I point out that with immutable objects this does not make much
> difference, but when we start dealing with mutable objects, it is important
> to be more precise. This sequence seems to work fine.
>
Sounds fine to me too.
Tuples may have mutable elements, but are immutable in the sense of having
just those elements (mutable or not, you can't add or remove them).
That's an important discussion, and not "advanced" as the idea of appending
to a list is as familiar as adding an item to a grocery cart.
These concepts are mundane, routine, not even that abstract. They are
anchored in ordinary language and everyday experience.
OK, I think that's enough reiteration to keep it clear. Objects do all the
work. Names are a means to that end, in providing the corresponding dot
notation syntax.
Kirby
>
> Andy
>
> Dr. Andrew N. Harrington
> Computer Science Department
> Graduate Program Director g...@cs.luc.edu
> Loyola University Chicago
> 529 Lewis Towers, 111 E. Pearson St. (Downtown)
> 417 Cudahy Science Hall (Rogers Park campus)
> http://www.cs.luc.edu/~anh
> Phone: 312-915-7982
> Fax: 312-915-7998
> ahar...@luc.edu (as professor, not gpd role)
>
> On Mon, Feb 15, 2016 at 8:58 PM, kirby urner <kirby.ur...@gmail.com>
> wrote:
>
>>
>>
>> On Mon, Feb 15, 2016 at 5:23 PM, Carl Karsten <c...@nextdayvideo.com>
>> wrote:
>>
>>> I think the point of this thread is: how important is this subject?
>>>
>>>
>> I don't know that there's a scale of 1-10 answer. If / when it comes up,
>> as a student question, it becomes important, but also instructors need to
>> explain how a given object may have many names, whereas of we're focused on
>> "containers" how does that look?
>>
>>
>>
>>> I have one of many answers: in my 2 hour 500 line intro to python, it
>>> gets about 60 seconds spent on this 1 line:
>>>
>>> """Other languages have variables; technically, Python doesn't. But it
>>> has something that looks like a var: It has names. So don't call it a var.
>>> For a good explanation of this see
>>> http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#other-languages-have-variables
>>> """
>>>
>>
>> This is excellent.
>>
>> I was racking my brains where to find visuals like this, specifically
>> showing the buckets versus post-its models.
>>
>> I've added links to my make_links_v2.py and make_links_v3.py @ <guild />
>> [1]
>>
>> This thread was useful for our trains at PDX Code Guild at least, as I'm
>> having philosophical differences with some of my peers regarding the
>> uber-basics and how best to teach them.
>>
>> I've been told repeatedly that code school students will start out *not*
>> knowing what a variable is and my number one most important responsibility,
>> right from the get go, is to introduce the concept.
>>
>> Fine. But what if the curriculum hard-codes that we should see variables
>> as "containers".
>>
>> Before I lead a boot camp, Python-centric, I want to make sure I'm not
>> shackled to a misinforming presentation I'm not comfortable teaching. It'd
>> just feel wrong, like I'm lying, to force the "container metaphor". I
>> needed ammo.
>>
>> By now, thanks to these threads today, I feel well armed in my views that
>> I'm free to avoid said metaphor if I want to.
>>
>> Here's a screen shot of our faculty Slack feed from a few minutes ago:
>>
>> https://flic.kr/p/DduBoA
>>
>> There's enough consensus out there to defend my position. Yay.
>>
>> What I want to avoid is another instructor insisting on the "variable as
>> container" metaphor to a point where I feel I have to do extra work to undo
>> that picture.
>>
>> Thanks again for the tools, should that come up.
>>
>> Kirby
>>
>> [1]
>> https://www.dropbox.com/home/PDX%20Code%20Guild/Accelerated%20Programming%20%28fork%29
>>
>>
>>
>>
>
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
https://mail.python.org/mailman/listinfo/edu-sig
