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
Re: [Edu-sig] Edu-sig Digest, Vol 39, Issue 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 << 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 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Fwd: [EuroPython] Children first and a hole-in-the-wall
interesting to: > > http://www.greenstar.org/butterflies/Hole-in-the-Wall.htm > An experiment worth doing once I suppose. Proves kids have natural ability that we mostly waste and squander. They deserve real opportunities though, not holes in the wall. Just like a Physicist to coldly treat them like guinea pigs. Continuing this experiment is a waste of time, and cruel. There are plenty of adults who could provide real guidance, lots of technological capability. We have no excuse to be doing "experiments" on these children. They should be given real opportunities. 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
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: > > 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] Talking about "Handles"
Am 03.10.2006 um 00:47 schrieb kirby urner: >> This metaphor may be good for references, but not for Python. You >> are >> left with the intuition that you can look at the mug and enumerate >> the >> handles. Maybe a an object is a living thing with lasers shining >> on it >> (referring to it), that may shrivel up and die if it gets no light. >> >> -- Scott David Daniels > > Good caveat. > > I could keep the "mug with many handles" metaphor, but then explain > only the Garbage Collector really knows when it's time for a mug to > meet its maker (i.e. return its piece of Memory to that great Heap in > the Sky). A mug to me sounds way too similar to "bit bucket". That's how low- level languages (like C++) present variables. Also, it's hard to imagine how to describe, say, a linked list as a chain of mugs. I like to explain objects as balloons, with labeled hooks on its surface as variables. A balloon can have more than one leash, but each hook holds exactly one leash (still looking for a metaphor that naturally has this constraint). Garbage collection then simply occurs when all leashes of an object are removed from the hooks - a whole tangle of objects might float up. The idea extends even to weak references, which is a leash not tied but loosely attached to a hook :) - Bert - ___ 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] Talking about "Handles"
(Fully aware of the potential problems of quoting out of context and of the limitation of using analogies...) On 10/2/06, Scott David Daniels <[EMAIL PROTECTED]> wrote: > I'm catching up here, and just read the namespaces thing -- > How about "namespaces are like card catalogs in a closed stack library." Analogies to library card catalogs would need to be explained to today's kids (including those 1st year university students). If any analogy is going to be used, I think it should be a future looking one - or, at least a "time-neutral" one. I'd prefer something like namespace <--> book variable/function/object name <--> character's name in a book two or more name for same object <--> character's name and alias(es) or nickname(s) That being said I believe that, just like for learning another "human" language, nothing beats the "immersion paradigm" to learn any language, including programming ones. Just introduce the vocabulary, use it in context with plenty of different examples and, soon enough, the students will construct their own "mental map" without referring to a translation in a different language. André Roberge ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Talking about "Handles"
> This metaphor may be good for references, but not for Python. You are > left with the intuition that you can look at the mug and enumerate the > handles. Maybe a an object is a living thing with lasers shining on it > (referring to it), that may shrivel up and die if it gets no light. > > -- Scott David Daniels Good caveat. I could keep the "mug with many handles" metaphor, but then explain only the Garbage Collector really knows when it's time for a mug to meet its maker (i.e. return its piece of Memory to that great Heap in the Sky). Kirby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Talking about "Handles"
I'm catching up here, and just read the namespaces thing -- How about "namespaces are like card catalogs in a closed stack library." At the Library of Congress (here in the U.S.), up through when I last went (some time ago), any U.S. citizen can go in and find a book in a catalog (I'm certain electronically automated by now) -- they are kind of sprinkled around as I remember), fill out a slip of paper, including a desk number, and wait at that desk. If no member of congress has the book out, it shows up on that desk, often in less than 20 minutes. If a book wound up in the library with no entries in any catalog, it would effectively be gone, whether or not the buildings vast archives held the book. The books don't care, however, how many different cards reference them (nor even if the only reference to them is written in some book which _is_ referenced by some card in the catalog). -- Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Talking about "Handles"
kirby urner wrote: > 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). This metaphor may be good for references, but not for Python. You are left with the intuition that you can look at the mug and enumerate the handles. Maybe a an object is a living thing with lasers shining on it (referring to it), that may shrivel up and die if it gets no light. -- Scott David Daniels [EMAIL PROTECTED] ___ 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
[Edu-sig] Fwd: [EuroPython] Children first and a hole-in-the-wall
Just saw this on the europython list :-- Forwarded message --From: Harald Armin Massa <[EMAIL PROTECTED] >Date: 02-Oct-2006 21:15Subject: [EuroPython] Children first and a hole-in-the-wallTo: "europython@python.org" < europython@python.org>Hello,all who were fascinated by the "children first" talk of Alan Key might find this article interesting to: http://www.greenstar.org/butterflies/Hole-in-the-Wall.htm So please try to imagine the possibilities given by OLPC with Python preinstalledHarald-- GHUM Harald Massapersuadere et programmareHarald Armin Massa Reinsburgstraße 202b 70197 Stuttgart0173/9409607-Python: the only language with more web frameworks than keywords. ___EuroPython mailing listEuroPython@python.org http://mail.python.org/mailman/listinfo/europython ___ 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=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 ___ 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 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
