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 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
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=1885docID=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 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
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 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
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 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
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 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
On 10/2/06, Arthur Siegel [EMAIL PROTECTED] 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 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
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 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
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 [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
