Divorce property objects from attribute access dependency?
Bengt Richter
bokr at oz.net
Sun Jun 16 14:39:44 EDT 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