Mutable class attributes are shared among all instances, is it normal ?

[Chris Barker]

Donn Cave wrote:

> I have no argument with the facts here, but I have to disagree about
> the reason for the confusion.

Of course, it's very difficult to ever know the reason for someone elses
confusion.

> It should be clear from this that the distinction between mutable
> and immutable objects here is actually completely irrelevant, 

I'm not sure it's completely irrelevant. The question is: are you
mutating an existing object, or are you re-assigning a name to a new
object. Since you can't do the former to an imutable object, it does
make a difference. Perhaps the real source of the confusion is that
assignement can be used to do both. The to newbe, the distiction
between:

l = [1,2,3]

and 

l[:] = [1,2,3]

is not terribly obvious. When you see:

l.append([1,2,3])

It's more obvious that you are changing something in place. 

Note that the original post asked about "Mutable class attributes", so I
did think the confusion had to do with mutable vs. not mutable. He was
trying to do the same thing with a mutable and a non-mutaable type, and
not getting the same results.

> and
> when we introduce this red herring into the picture we make a simple
> matter much harder to understand.  (It's so often repeated here, yet
> makes no sense to me.  I don't wish to pick on this post, the author
> went went to considerable trouble to help out and I'm just off on a
> rant about this detail, because the subject has the word "mutable".)

I don't feel picked on. I think this is always a difficult subject for
new users to get a handle on, I know it took me a while. I'd love to
find the best way to explain it.

> When I write "self.x = a", it does not matter in any way whether
> self.x is mutable.  It is purely irrelevant.

true, and I did try to make that clear.
 
> To understand why "self.x = a", we really have to understand the
> Python object/reference/namespace model, which again has nothing
> to do with mutability.  If you understand what "self.x = a" means
> in that model ("make name 'x' in namespace 'self' refer to the
> same object as name 'a' in the default namespace[s], possibly
> hiding another name in a posterior namespace" ... uh, there has
> to be a better way to say that!)

We really do need to find a better way, I wish I had it! That wasn't
bad, however.

> Now I think what people mean to point out here, is that given the
> realities of life with Python, one may choose to substitute
> "self.x = a" with some expression that modifies a mutable object,
> like "self.x[0] = a".  That's fine, but of course the point is
> not that self.x is mutable, the point is that you are modifying it.

I think the point is not that self.x is mutable, but that self.y is NOT
mutable. In other languages, x points to a particular piece of memory,
and if you write x = somethingnew, that same memory is being used. In a
number of begining programming texts I have seen variables described as
boxes that numbers can be put in. Python mutable types can be boxes, and
their contents changed without changing the box intself, but python
imutable types are NOT boxes, so the distinction is important.

Now I have to wonder if the original poster is more or less confused.

-Chris


-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------