En Tue, 26 Feb 2008 05:58:52 -0200, <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
