Scope rule pecularities

[Donn Cave]

In article <slrnca4693.1i9.apardon at trout.vub.ac.be>,
 Antoon Pardon <apardon at forel.vub.ac.be> wrote:

> Op 2004-05-12, Duncan Booth schreef <me at privacy.net>:
> > Antoon Pardon <apardon at forel.vub.ac.be> wrote in 
> > news:slrnca428q.1i9.apardon at trout.vub.ac.be:
> >
> >> IMO lacking an assignment that copies the value
> >> of one object into another was a mistake and
> >> which creats IMO a lot of difficulties.
> >> 
> >> If I have a function with an object as a paramter.
> >> and this object is mutable. Now within this function
> >> I find a second object with the value I want the
> >> argument to have. Now I can't simply copy the
> >> second object over the argument but I have to
> >> copy attribute by attribute from the second object
> >> into the argument.
> >
> > Why wouldn't you just return the second value (or a copy of it) as a result 
> > from the function? That is usually a more flexible choice since it gives 
> > the caller the option of either replacing the original value or using the 
> > modified value somewhere different.
> 
> Well because the object could be bound with more than one name.
> 
> > Anyway, if you really need to do this then the mutable object should have 
> > some sort of updateState method which takes the second object as a 
> > parameter. That way the original object can have control over which 
> > attributes get overwritten and which don't.
> 
> And I think it is a pain in the butt to always have to write such an
> UpdateState method whenever you want one object to be copied in place
> from an other.

I really think this is a cases where you will write better
programs if you let yourself be guided by what you can do
in idiomatic Python.

In modern programming, now that we have pretty much adopted
the "structured" programming model, one of the main remaining
burdens on the programmer is "mutable state".   You need to
be able to account for possible changes in values, if you
want to be able to reason about your program.  Python isn't
any kind of extreme solution to this problem, it isn't a
"pure" functional language, but it does have some helpful
constraints and this is one of them - you know a function
can't rebind names that you supply as its parameters.  The
inability to do this is a feature.

   Donn Cave, donn at u.washington.edu