Divorce property objects from attribute access dependency?

Bengt Richter bokr at oz.net
Sun Jun 16 20:39:44 CEST 2002


 >>> class C(object):
 ...     def __init__(self,v):
 ...         self._v = v
 ...     def get_v(self): return self._v
 ...     def set_v(self,v): self._v = v
 ...     v=property(get_v,set_v)
 ...     vlist = [v,v]
 ...
 >>> c=C('something')
 >>> c.v
 'something'
 >>> c.v='other'
 >>> c.v
 'other'
 >>> c.vlist
 [<property object at 0x0082D4A0>, <property object at 0x0082D4A0>]
 >>> c.vlist[0]
 <property object at 0x0082D4A0>

Why not trigger get_v() in these accesses too, and have single mechanism to
suppress it instead of a single mechanism to effect it?

ISTM kind of a hack to rig access via instance attribute as a mechanism for controlling
referenced-object behavior (this is my impression, I haven't checked code ;-). IMO default
behavior of an object in lhs or rhs context should not depend on how a reference to it was
acquired and dereferenced.

(Obviously, if property objects always acted as they now do through instance attribute
access, "vlist=[v,v]" in this example would have to have some kind of access override like
"vlist = [obj(v),obj(v)]", or else it would generate ['something','something'] right there.
Using obj(p) a property object could be passed around without evaluation and the potential
side effects thereof).

BTW, it would be nice to be able to define a property at global module scope also,
and perhaps this would tie in nicely.

Just musing ;-) Thoughts? Am I missing a big gotcha?
One thing is that it will effectively make possible a ()-less function call, which will
upset some people ;-)

Regards,
Bengt Richter



More information about the Python-list mailing list