along the lines, hash and obj. id.

[Gabriel Genellina]

En Tue, 26 Feb 2008 05:58:52 -0200, <castironpi at gmail.com> escribió:

> It works to keep a reference to the object, then access the member
> again.  If your only reference to the object is the member itself,
> obj.a= {} breaks d, but obj.a.clear() keeps it alive.
>
> In the case of immutables, there is no such .clear() equivalent.  If
> obj.a is a tuple, string, or integer (*miss any?), d is always broken
> when obj.a is changed.

"when obj.a is changed": That may have two meanings:

a) "when the object itself referenced by obj.a is modified" or
b) "when obj.a is made to refer to another object"

For a), you use something like obj.a.somemethod(). "obj.a" still refers to  
the same object, even if it changed internally; if obj.a and foo.bar both  
were refering to the same object, they still do. [1]
For b), you have to rebind the name using any statement with such effects  
(assignment, for, with, import...); in this example, as obj.a is an  
attribute reference, the only allowed forms are assignments: obj.a =  
something (including augmented assignments obj.a += something). If obj.a  
and foo.bar both were previously refering to the same object, you can't  
guarantee that after executing such statements.

> The generic solution involves a second level of indirection: tuple* d=
> &obj.a.  I can't land a clean solution to it though.

(Forget about C and pointers... you'll just confuse things this way.  
Python has objects and names that refer to them, not pointers and  
variables with allocated storage and type.)

Depending on the requirements, there are several answers. You may  
distinghish "some" place as "the" official place where the object lives,  
and make all other retrieve it from there when needed. Or use a  
notification mechanism when its value changes. Or wrap the value into  
another shared object.

[1] Assuming somemethod() isn't evil and rebinds obj.a itself...

-- 
Gabriel Genellina