Dennis Lee Bieber wrote: > On Mon, 24 Jul 2006 17:35:50 -0300, Gerhard Fiedler <[EMAIL PROTECTED]> > 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 -- http://mail.python.org/mailman/listinfo/python-list
