[Edu-sig] Python for Beginners

[Paul Gries]

I give a lecture early on in my CS1 course on assignment and objects  
and computer memory and so on.  I think I enjoy it way more than my  
students, but it's a fun model to draw on the board and trace a small  
program with.

I start by telling them that writing a program is, ultimately, giving  
the computer a script to follow, telling it how to manipulate memory  
and interact with the user.  But the computer is pedantic, so you have  
to be careful what you tell it to do.  In order to be careful, you  
have to have a mental model that corresponds with how the computer  
actually works.  Here's one model that's pretty close; I tell my  
students that there are lots of other analogies, but that all of them  
have to match the computer's behavior.

Computer memory is like a really long street, with tons and tons of  
houses, each with its own unique number.  A variable is a little piece  
of paper with a name and an address written on it.  A house is a place  
for storing some data, along with written descriptions of how to do a  
small set of very specific tasks.

In an assignment statement x = y, we copy y's address onto x's sheet  
of paper.  To relate this to Kirby's URL example, you don't even need  
to know what's in the house at that address in order to do this, or  
how far away it is.

There are lots of different kinds of things you can put into a house:  
an int value and descriptions of tasks related to that int value; a  
string value and descriptions of tasks that related to string-related  
tasks.  You can also put variables (pieces of paper each with a name  
and an address) in a house.

You need worker robots to follow the task descriptions.  These  
represent functions that are currently executing.  Workers carry  
around a set of local variables (again, pieces of paper).  Workers can  
summon other workers whenever they need to.  Workers can go to a house  
(on the bus?) and fetch a piece of information, or summon another  
robot worker to a house to do a task.  The worker waits patiently for  
the task to be finished---they know which worker they're waiting for,  
which gives us a call stack---and then brings back the result to  
wherever they came from.

Does it work?  I think it helps some people.  It certainly helps  
demystify the concept of memory addresses, which lots of new  
programmers find surprisingly intimidating.

Later in the course, I draw the call stack and the heap and talk about  
real memory addresses; help(id) says "Return the identity of an  
object. ... (Hint: it's the object's memory address.)".  Now we can  
quiz a variable about which house it points to, which can help them  
understand the debugger.  I also go back to the street analogy when I  
talk about recursion, and they don't seem to have any trouble with the  
idea that a robot with a set of instructions can summon another robot  
to follow the same set of instructions, and the behavior might be  
different if the second robot's variable values are different from the  
first.

-Paul


On 23-May-08, at 13:00 , kirby urner wrote:

> I think in an Intro to Programming course featuring Python or not,
> it'd make sense to talk a lot about this new use of the equality
> symbol ( = ) and how language designers have felt about it (suspicious
> in some cases).
>
> In APL, a left pointing arrow was used.  PL/1 used := as I recall.
> What other symbols for "assignment"?  Class project, to collect?
>
> In math books, they sometimes write out Let x =, which has that
> imperative flavor, that commanding tone (who is x to fight back
> anyway, variables so pliable, whereas in CS we have to "allocate
> memory" meaning the department might give us a budget, at least in the
> old time share days, getting "an account" i.e. CPU time, was
> considered a real privilege, so any "x =" is ultimately gonna cost ya,
> in adding to a namespace (a finite resource)).
>
> In any case, there's that big gulf between asserting these two are
> equal, versus the one on the right giving new information to the one
> on the left, passing something on, in a specific direction.
>
> So what gets passed on?
>
> A beginner seeing x = y = z = 8 won't know if that's in Python or what
> (nor will an expert for that matter, until a context is provided).
>
> In Python, x = y = z = 8 says the information on the whereabouts of 8
> is trickling through this pipe and collecting in pools z, y, and x
> respectively.
>
> After this transaction, z, y and x have no ongoing relationship with
> one another.  This is true regardless of whether 8 is an integer, or
> some mutable object *disguised* as an integer (pretty clever disguise,
> not legal in Python).
>
> The model I've been using is:  I'm walking the dog, then hand you a
> leash.  Now we both have a leash to the same dog.
>
> A problem with this imagery is it keeps you and I in proximity, as
> "walking the dog" is a "crowding together", something that moves us
> along the sidewalk, tethered to a four-legged.
>
> Post-its also have this problem of needing to be physically connected
> to things (that's the hallmark of post-its, they stick to stuff).
>
> In the shoptalk of mathematicians, both the leash and the post-it
> analogy imply a "metric" i.e. give us a strong sense of the physical
> distances involved.
>
> The idea of an astronaut floating in space, connected by a long cord
> to the space station, shuttle, other craft, is a step closer to the
> imagery we're seeking.
>
> Where I ended up earlier is with this idea of a website address, a
> pointer through the Internet to something with an IP number, similar
> to a Python memory id number, as in id( x ).
>
> We think more clearly only about the topology then, realize right off
> the bat we have no way of knowing what physical distances might be
> involved, so best to not imagine them.
>
> When I go y = x in Python, it's like x emailing a web address to y.  x
> doesn't lose any information in sending that URL and y may later
> rebind to something else, but so long as x and y share the same URL,
> they both look at the same website.
>
> They *do not* look at each other however.  The assignment operator ( =
> ) triggers a fleeting ocurrance, an event, a hand-off (except the
> provider hands off a duplicate -- this is "copy" not "move" (what true
> beginners are likely familiar with, given at least minimal GUI-based
> file management experience)).
>
> Given we're mostly seasoned programmers in this group, write code for
> a living, for school, for industry, we might not remember how odd this
> new use of = might have seemed at first.
>
> To a chemistry major, = looks a lot like a double bond.
>
> To a mathematician, = might look like an assertion of some eternal
> relationship.
>
> Either way x = y might come across as "static through time" in some
> way, whereas in many computer languages (I'm not saying all), we're
> talking about a quick happening, a few nanoseconds or clock cycles,
> then it's all over.
>
> More like mitosis than anything, in that one variable became two.   
> And so on.
>
> All that being said, after x = y, x and y *do* have a sameness we can
> check, in that both now fit the category of "pointing to object X".
>
> That's what the "is" operator is for in Python as in x is y (returns  
> True).
>
> "==" is for something else again, and triggers the __eq__ rib.
>
> We know what == means in the case of integers, string objects, but
> it's up to the programmer to apply spin for programmer-defined
> objects, by writing code for that special name (or not -- nothing much
> is mandatory in Python, which we like).
>
> Kirby
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig