Nested function scope problem

[Steve Holden]

Dennis Lee Bieber wrote:
> On Mon, 24 Jul 2006 17:35:50 -0300, Gerhard Fiedler <gelists at gmail.com>
> declaimed the following in comp.lang.python:
> 
> 
>>It is surprising in the sense that binding seems not to be necessary for
>>read access. 
>>
It does, I would agree, seem a little counter-intuitive that assignment 
(or binding) forces the name to be considered local. That's just one of 
Python's features.
> 
> 	Binding is the process of attaching the LHS NAME to the OBJECT that
> is RHS result.
> 
> 	Python does not use the "mailbox model" of variables. In the mailbox
> model (think of a post office sorting table, or the customer boxes in
> the lobby), each "box" has one, and only one, name.
> 
> 	A = B
> 
> means "take the contents of box B, make a copy of those contents, leave
> the original contents in B, and put the copy into box A"
> 
> 	Python has what I refer to as the "Post-It Note Model".
> 
> 	A = B
> 
> means "find the box that has a post-it note with 'A' (if there isn't
> one, get a blank note and put 'A' on it), take that post-it note and
> move it to the box that already has a post-it note with 'B' ". Notice
> that this means that THAT box (the object) NOW has TWO Post-It notes,
> each with a different "name".
> 
I've never really understood the value of the "Post-It" analogy. Despite 
the fact that it allows you to explain that objects can have several 
names, it doesn't really help in explaining that the names themselves 
live in particular namespaces and have lifetimes largely independent of 
the objects to which they refer.

It really seems easier (to me) to explain that names are references or 
pointers to values, and that the names live in scopes that can disappear 
(for example when a function or method returns). This also allows one to 
explain that a function can return references to (one or more) objects, 
and if those references are saved by the caller then the lifetime of the 
referenced object(s) can be longer than the lifetime of the namespace in 
which they were originally created.

> 	Lists/dictionaries/tuples, etc. complicate this a small bit. What
> you now have is the "object" (the box with the name of the list on it)
> having a lot of pieces of "string" -- each string is stuck to a post-it
> note with the final object. This is why
> 
> 	A[1] = B
> 
> is not a rebinding of A. It looks for the box with the post-it of A,
> then gets the second (0 is first) "string" and follows that string to
> the post-it it is stuck on... That end of the string is then moved to
> the post-it with the name B

Well here I'd rather simply say that references can also be saved in 
container objects, with all the same implications as when they are saved 
in names.

This is explained extremely well in Ascher and Lutz's "Learning Python" 
(at least in my first edition copy) using diagrams that make it obvious 
how objects are created and what their lifetimes are likely to be.

All this business about Post-It notes and pieces of string seems 
artificial in the extreme, not to say a little unhelpful. Maybe I've 
just been programming too long ...

Perhaps you'd like to try explaining argument passing in terms of 
Post-Its? That might be amusing ;-)

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd          http://www.holdenweb.com
Skype: holdenweb       http://holdenweb.blogspot.com
Recent Ramblings     http://del.icio.us/steve.holden