Re: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
Kirby said:
We say "reference" a lot when talking about a variable's relationship to a piece of memory. I'm thinking "handle" could be used more (optionally -- this is not an instruction) and we could even show a coffee cup (doesn't have to be coffee -- a mug) with two handles, when explaing how two (or more) variables may have the same "contents" (a feature, but also a source of bugs, confusions for beginners).
Picking a good metaphor, tailored to the pedagogical situation, is very important: it provides the critical cognitive bridge from what the student *already* knows to what you want the student to *learn*. The best metaphor I've encountered for the concept of variable, as implemented by Python, is John Zelle's. On page 34 of "Python Programming: An Introduction to Computer Science", he says: Assigning a variable is like putting one of those little yellow sticky notes on the value and saying, "this is x." Thinking "sticky note" makes it easy to teach students that: * Even if "x" is already assigned to one value, you can assign it to another value. (Take the note off the first value, and stick it onto the second one.) * In Python, any variable can be assigned to any value. (By contrast, some languages have "colored sticky notes", and you can't stick a BLUE sticky note on a RED value). John Z, do you take this angle in your book? I didn't see it, but I confess I may have failed to look thoroughly enough for it! * You can assign "x" and "y" (etc.) to the same value. (You can place any number of sticky notes on the same value. A note is always attached to a value -- a note is never attached to another note.) * Jut what does the "del" statement actually do? (It removes one sticky note from a value. If a value loses all its sticky notes, it becomes totally *incommunicado* -- there's no way to get to the value.) * What's a namespace? (A bunch of sticky notes.) * etc., etc. The coffee-cup-handle metaphor is certainly useful, but IMHO not quite as spot-on as the sticky-note metaphor. -John Posner
The coffee-cup-handle metaphor is certainly useful, but IMHO not quite as spot-on as the sticky-note metaphor.
-John Posner
Excellent review John thanks. Below is the kind of thing a teacher could project. IDLE 1.2b2
handle1 = ['coffee','sugar','cream'] handle2 = handle1
id(handle1) 13645944
id(handle2) 13645944
handle1.sort() # alphabetize in place
handle2 ['coffee', 'cream', 'sugar']
handle3 = handle1 handle3 is handle2 True
So by this time with have a list in Memory with three handles (handle1, handle2, handle3). The idea of a cartoon mug with more than one handle seems "sticky" in the sense that students are unlikely to forget it easily. BTW, I just searched and found a real two-handled mug for sale in Ireland: http://www.assistireland.ie/index.asp?locID=1885&docID=1742 One reason I like this "handle" nomenclature is kids use "handles" for themselves, i.e. for chat rooms, other places where some notion of primitive identity is required (Second Life is especially popular these days). So there's already this builtin sense of "me" (myself) with multiple handles, multiple ways for others to get in touch with the same identity. I like the idea of making Memory a spatial affair i.e. instead of just using flat rectangles or circles to represent contents, we could use 3D-looking balloons or balls. Balloons with multiple strings is a good analogy (or just the one string). When no strings attach, the balloon simply floats off, out of sight out of mind (out of Memory). Cartoon animations of Garbage Collection: what should those look like? We need to connect here: a discussion of immutability. A list can be shaken and stirred without losing its identity. However, strings are considered immutables in Python, meaning if you fix a typo, you get back a new string, not a change in the original Memory container. Tuples are similar, in that you can't change the handles inside a tuple -- but you *can* change the Memory contents of what the handles point to, e.g.:
mytuple = (handle1, handle2, handle3) mytuple[1] ['coffee', 'cream', 'sugar'] handle3[2] = 'vanilla flavoring' mytuple[1] ['coffee', 'cream', 'vanilla flavoring']
What's a good metaphor for explaining about intern?
help(intern) Help on built-in function intern in module __builtin__:
intern(...) intern(string) -> string ``Intern'' the given string. This enters the string in the (global) table of interned strings whose purpose is to speed up dictionary lookups. Return the string itself or the previously interned string object with the same value.
Kirby
On Mon, 2006-10-02 at 10:00 -0700, kirby urner wrote:
handle1 = ['coffee','sugar','cream'] handle2 = handle1
id(handle1) 13645944
id(handle2) 13645944
I always thought that when presenting this it is natural and important - in order for the student to truly get it - to do an "as opposed to" thingy.
handle3=list(handle1) handle1[0]='tea' handle1 ['tea','sugar','cream'] handle3 ['coffee','sugar','cream']
To me this is so essential that I have argued that the fact that neither the list type having a copy method or the copy function being a built-in is a wart. But I think if it is a wart it impacts discovering Python, i.e. self-teaching, rather than teaching Python and learning Python more formally. Anyway, I would advocate the "as opposed to" be integrated into such a presentation. Art
Anyway, I would advocate the "as opposed to" be integrated into such a presentation.
Art
Yes, once bitten in the butt by the fact of a two handled mug, then comes the question: "so how do I make sure each handle gets a mug to itself?" (as in "why should we share the same beer?"). At this point, we have a couple of trix, one of which you mentioned (use list(input) to return another list). Or we might import the copy module. Or we might "take the whole thing as a slice" i.e. newlist = oldlist[:]. However, the list and slice functions aren't generic enough to work for generic objects. I think the key here is to refer to "=" (the equal sign) as an operator, i.e. a "doer" (we're not asserting the identity of two objects (as in pre-computer algebra) but assigning a handle to a piece of memory, giving it a name. I'm thinking astronomy might come in useful here. Two namespaces (mythologies) might connect the stars into completely different creatures, surrounded by their own respective stories. You can get away with this, even if we don't admit to parallel universes thereby (same stars, different tellings). Actually *duplicating* a piece of memory (wasteful?), to make the same contents reside elsewhere (why?), with its own handles, is considered a semi-esoteric move in Python, not something you'd necessarily need right out of the box. There's a builtin bias against it (duplication), because Memory should be retreated with respect as a finite resource, not squandered unnecessarily. But if you *really* need to clone a piece of memory (vs. simply assign it a new handle), then by all means, import the copy module and even a deepcopy if you need to. You have that freedom. But it's a step away from an everyday operation. As far as beginners are concerned, they may come to Python with the expectation that duplicating objects willy nilly is the mark of a good program ("memory is cheap" we're always saying these days). Setting them up for a surprise may actually be good pedagogy. Maybe some teacher text (not necessarily printed) wants to do a "Snake Bite" icon, with the spin that here's a potential pitfall, but also a useful lesson, should you fall into it (we learn from these snake bites and move on). Kirby
On Mon, 2006-10-02 at 16:04 -0700, kirby urner wrote:
Anyway, I would advocate the "as opposed to" be integrated into such a presentation.
Art
Actually *duplicating* a piece of memory (wasteful?), to make the same contents reside elsewhere (why?), with its own handles, is considered a semi-esoteric move in Python, not something you'd necessarily need right out of the box.
In my mind, it is not a matter of needing copy right out of the box. And that is the argument I keep running into when making this general case - that teaching "copy" - in any form - early overemphasizes something that is "semi-esoteric". And I understand that point. Except that mutable/non-mutable is cognitively more than semi-esoteric for the uninitiated. While there certainly is nothing in the least esoteric about the list data-type or the assignment operator. The argument I keep making and for which I cannot seem to find any takers, is that essential to explaining/understanding assignment of a list to a name, is understanding in the negative - i.e., what it is not. We are still just teaching basic assignment with regard to a list, and I maintain that doing so effectively should in part be done in the negative. What it is not silhouetting better what it is. Art
On 10/2/06, Arthur Siegel <ajsiegel@optonline.net> wrote:
The argument I keep making and for which I cannot seem to find any takers, is that essential to explaining/understanding assignment of a list to a name, is understanding in the negative - i.e., what it is not. We are still just teaching basic assignment with regard to a list, and I maintain that doing so effectively should in part be done in the negative. What it is not silhouetting better what it is.
Art
I'm pretty sure I follow. I might spin this away from "lists" per se, as the multiple references to one object in memory picture is not narrowly about just lists, but any objects, as you well know. A generic way to initialize an object:
o = object()
The mutability vs. immutability thing is inextricably woven in to the assignment thread, because of what we're able to do with tuples: mutate objects in memory without disturbing their tupuloids i.e. change the contents of a list *in* a tuple.
thelist = ['a'] thetuple = (thelist,) thetuple[0][0] = 'b' # not mutating thetuple, but memory object within thetuple (['b'],)
When I say something is "semi-esoteric" I'm not arguing that it's discussion be postponed for very long. More it's a rationale for the *design* of Python, i.e. why "copy" requires an import and isn't a builtin. Esoteric books are on a higher shelf -- but that doesn't mean you can't grab them down even on the very first day, if your students are ready to move quickly. Scott mentioned our not being able to see how many handles a mug has, but with the sys module we can: IDLE 1.2b2
import sys a = ['mug of beer'] b = a c = a sys.getrefcount(a) 4 del c sys.getrefcount(a) 3 help(sys.getrefcount) Help on built-in function getrefcount in module sys:
getrefcount(...) getrefcount(object) -> integer Return the reference count of object. The count returned is generally one higher than you might expect, because it includes the (temporary) reference as an argument to getrefcount(). "As a former philosophy major, it disturbs me to think that things disappear when no one is looking at them, but that's exactly what happens in Python. In general, you can simply forget about memory management and let Python clean up after you." -- Mark Pilgrim Kirby
kirby urner wrote:
Scott mentioned our not being able to see how many handles a mug has, but with the sys module we can: .... Perhaps I said that, but what I _meant_ was that you could see the handles. In my mind, at least, there is a huge difference between seeing the handles (what is this value's name?) and knowing how many there are. I just don't know a nifty concrete-world analog to that. The Library of Congress idea (too flawed, I agree) was neat because objects (books) could become "lost" without a librarian noticing. Then on to: "Well, if there were a count, and, ......"
-- Scott David Daniels Scott.Daniels@Acm.Org
On Oct 3, 2006, at 12:50 AM, Scott David Daniels wrote:
kirby urner wrote:
Scott mentioned our not being able to see how many handles a mug has, but with the sys module we can: .... Perhaps I said that, but what I _meant_ was that you could see the handles. In my mind, at least, there is a huge difference between seeing the handles (what is this value's name?) and knowing how many there are. I just don't know a nifty concrete-world analog to that. The Library of Congress idea (too flawed, I agree) was neat because objects (books) could become "lost" without a librarian noticing. Then on to: "Well, if there were a count, and, ......"
I use a street metaphor. (Which is where some of the lingo comes from anyway, isn't it?) As a quick summary, houses are areas in memory and each has a unique address; people (variables) know the house they live in; a person's value is just the address of their house; x = y makes x live in the same house as y, and they can rummage in each other's personal belongings; deep copies are a lot of work; the contents of a house are accessible only to people who have the address; the number of people living in a house isn't immediately obvious; and when everybody moves out of the house, all the leftover stuff gets garbage collected. Oh, and if you've talked about hardware at all you can make jokes about carrying things about on the bus. Other similar things I've tried: warehouses with storage locations, apartment buildings, and offices. Those didn't seem to work as well, but I tried them early on before I settled on streets; maybe they'd work out better today. -- Paul Gries Senior Lecturer, Dept. of Computer Science University of Toronto
On Mon, 2006-10-02 at 16:04 -0700, kirby urner wrote:
Or we might import the copy module.
Or we might "take the whole thing as a slice" i.e. newlist = oldlist[:].
I used the list(handle1) alternative purposefully, based on Alex Martelli's position on the matter. The first time I heard him state a position on it was in an exchange on python-list in which I participated precisely on the subject under discussion re:referencing and copying It was one of the more satisfying discussions I have had on python-list. Apparently what I was saying was in line with some other discussion he has having with Anna re: CookBook2, and it seemed to have some influence in how he intended to approach the issue on "copy" in that edition. Don't know the end result, as I have CookBook1 and haven't sprung for 2. Here is a reference to that thread http://mail.python.org/pipermail/python-list/2004-August/237278.html Guido knows that this is a favorite topic of mine and has considered me quite the nudge for returning to it as often as I do. Art
Here is a reference to that thread
http://mail.python.org/pipermail/python-list/2004-August/237278.html
Guido knows that this is a favorite topic of mine and has considered me quite the nudge for returning to it as often as I do.
Art
<< filing URL for possible follow-up someday >> Sounds like you've got something nailed. I'll leave ya to it then. Edu-sig has nothing to do with all of us agreeing to teach the same way. I hope I've been plenty clear that I'm interested in *competing* with other teachers (in a friendly give and take way), more than trying to tell them their jobs -- it's more fun that way, and way more productive. Kirby
participants (5)
-
Arthur Siegel -
John Posner -
kirby urner -
Paul Gries -
Scott David Daniels