Robin Becker a écrit :[color=blue]
> Is there a way to override a data property in the instance? Do I need to
> create another class with the property changed?[/color]
On Mon, 17 Oct 2005 18:52:19 +0100, Robin Becker <robin@reportla b.com> wrote:
[color=blue]
>Is there a way to override a data property in the instance? Do I need to create
>another class with the property changed?[/color]
How do you need to "override" it? Care to create a toy example with a
"wish I could <override action> here" comment line? ;-)
On 17 Oct 2005 11:13:32 -0700, "SPE - Stani's Python Editor" <spe.stani.be@g mail.com> wrote:
[color=blue]
>No, you can just do it on the fly. You can even create properties
>(attributes) on the fly.
>
>class Dummy:
> property = True
>
>d = Dummy()
>d.property = False
>d.new = True
>[/color]
a simple attribute is not a property in the sense Robin meant it,
and a "data property" is even more specific. See
also
[color=blue][color=green][color=darkred]
>>> help(property)[/color][/color][/color]
Help on class property in module __builtin__:
class property(object )
| property(fget=N one, fset=None, fdel=None, doc=None) -> property attribute
|
| fget is a function to be used for getting an attribute value, and likewise
| fset is a function for setting, and fdel a function for del'ing, an
| attribute. Typical use is to define a managed attribute x:
| class C(object):
| def getx(self): return self.__x
| def setx(self, value): self.__x = value
| def delx(self): del self.__x
| x = property(getx, setx, delx, "I'm the 'x' property.")
|
Bruno Desthuilliers wrote:[color=blue]
> Robin Becker a écrit :
>[color=green]
>> Is there a way to override a data property in the instance? Do I need
>> to create another class with the property changed?[/color]
>
>
> Do you mean attributes or properties ?[/color]
I mean property here. My aim was to create an ObserverPropert y class
that would allow adding and subtracting of set/get observers. My current
implementation works fine for properties on the class, but when I need
to specialize an instance I find it's quite hard.
Robin Becker wrote:[color=blue]
> Bruno Desthuilliers wrote:
>[color=green]
>> Robin Becker a écrit :
>>[color=darkred]
>>> Is there a way to override a data property in the instance? Do I need
>>> to create another class with the property changed?[/color]
>>
>>
>>
>> Do you mean attributes or properties ?[/color]
>
>
> I mean property here.[/color]
Ok, wasn't sure... And sorry, but I've now answer.
[color=blue]
> My aim was to create an ObserverPropert y class
> that would allow adding and subtracting of set/get observers.[/color]
Could you elaborate ? Or at least give an exemple ?
[color=blue]
> My current
> implementation works fine for properties on the class, but when I need
> to specialize an instance I find it's quite hard.[/color]
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom. gro'.split('@')])"
Robin Becker <robin@SPAMREMO VEjessikat.fsne t.co.uk> wrote:
[color=blue]
> Bruno Desthuilliers wrote:[color=green]
> > Robin Becker a écrit :
> >[color=darkred]
> >> Is there a way to override a data property in the instance? Do I need
> >> to create another class with the property changed?[/color]
> >
> > Do you mean attributes or properties ?[/color]
>
> I mean property here. My aim was to create an ObserverPropert y class
> that would allow adding and subtracting of set/get observers. My current
> implementation works fine for properties on the class, but when I need
> to specialize an instance I find it's quite hard.[/color]
A property is an 'overriding descriptor', AKA 'data descriptor', meaning
it "captures" assignments ('setattr' kinds of operations), as well as
accesses ('getattr' kinds), when used in a newstyle class. If for some
reason you need an _instance_ to bypass the override, you'll need to set
that instance's class to one which has no overriding descriptor for that
attribute name. A better design might be to use, instead of the builtin
type 'property', a different custom descriptor type that is specifically
designed for your purpose -- e.g., one with a method that instances can
call to add or remove themselves from the set of "instances overriding
this ``property''" and a weak-key dictionary (from the weakref module)
mapping such instances to get/set (or get/set/del, if you need to
specialize "attribute deletion" too) tuples of callables.
bruno modulix wrote:
......[color=blue]
>
> Could you elaborate ? Or at least give an exemple ?[/color]
......
in answer to Bengt & Bruno here is what I'm sort of playing with. Alex suggests
class change as an answer, but that looks really clunky to me. I'm not sure what
Alex means by
[color=blue]
> A better design might be to use, instead of the builtin
> type 'property', a different custom descriptor type that is specifically
> designed for your purpose -- e.g., one with a method that instances can
> call to add or remove themselves from the set of "instances overriding
> this ``property''" and a weak-key dictionary (from the weakref module)
> mapping such instances to get/set (or get/set/del, if you need to
> specialize "attribute deletion" too) tuples of callables.[/color]
I see it's clear how to modify the behaviour of the descriptor instance, but is
he saying I need to mess with the descriptor magic methods so they know what
applies to each instance?
## my silly example
class ObserverPropert y(property):
def __init__(self,n ame,observers=N one,validator=N one):
self._name = name
self._observers = observers or []
self._validator = validator or (lambda x: x)
self._pName = '_' + name
property.__init __(self,
fset=lambda inst, value: self.__notify_f set(inst,value) ,
)
def __notify_fset(s elf,inst,value) :
value = self._validator (value)
for obs in self._observers :
obs(inst,self._ pName,value)
inst.__dict__[self._pName] = value
def add(self,obs):
self._observers .append(obs)
def obs0(inst,pName ,value):
print 'obs0', inst, pName, value
def obs1(inst,pName ,value):
print 'obs1', inst, pName, value
class A(object):
x = ObserverPropert y('x')
a=A()
A.x.add(obs0)
a.x = 3
b = A()
b.x = 4
#I wish I could get b to use obs1 instead of obs0
#without doing the following
class B(A):
x = ObserverPropert y('x',observers =[obs1])
Robin Becker wrote:[color=blue]
> Is there a way to override a data property in the instance? Do I need to create
> another class with the property changed?
> --
> Robin Becker[/color]
It is possible to decorate a method in a way that it seems like
property() respects overridden methods. The decorator cares
polymorphism and accesses the right method.
Kay Schluehr wrote:[color=blue]
> Robin Becker wrote:
>[color=green]
>>Is there a way to override a data property in the instance? Do I need to create
>>another class with the property changed?
>>--
>>Robin Becker[/color]
>
>
> It is possible to decorate a method in a way that it seems like
> property() respects overridden methods. The decorator cares
> polymorphism and accesses the right method.
>
> def overridable(f):
> def __wrap_func(sel f,*args,**kwd):
> func = getattr(self.__ class__,f.func_ name)
> if func.func_name == "__wrap_fun c":
> return f(self,*args,** kwd)
> else:
> return func(self,*args ,**kwd)
> return __wrap_func
>
>
> class A(object):
> def __init__(self, x):
> self._x = x
>
> @overridable
> def get_x(self):
> return self._x
>
> x = property(get_x)
>
> class B(A):
>
> def get_x(self):
> return self._x**2
>
> class C(B):pass
>
>[color=green][color=darkred]
>>>>a = A(7)
>>>>a.x[/color][/color]
>
> 7
>[color=green][color=darkred]
>>>>b = B(7)
>>>>b.x[/color][/color]
>
> 49
>[color=green][color=darkred]
>>>>c = C(7)
>>>>c.x[/color][/color]
>
> 49
>[/color]
I thought that methods were always overridable. In this case the lookup on the
class changes the behaviour of the one and only property.
Steven Bethard wrote:[color=blue]
> Robin Becker wrote:
>[/color]
........[color=blue]
>
> Can you add the object to be observed as another parameter to the add
> method?
>
> py> class ObservablePrope rty(property):
> ... def __init__(self, *args, **kwargs):[/color]
.......[color=blue]
> py> A.x.add(b, obs2)
> py> b.x = 7
> obs2: 7
>
> Probably "self._observer s" should use some sort of weakref dict instead
> of a regular dict, but hopefully the idea is clear.
>
> STeVe[/color]
yes I think this is what Alex is proposing. It probably means abandoning the
class based observers entirely otherwise there would have to be a decision on
whether the instance observers take priority and some argument convention on
whether the class or the instance was being added to.
--
Robin Becker
Robin Becker wrote:
[color=blue]
> I thought that methods were always overridable.
> In this case the lookup on the
> class changes the behaviour of the one and only property.[/color]
How can something be made overridable that is actually overridable? I
didn't know how to better express the broken polymorphism of Pythons
properties than by stating it as a pleonasm about the used get and set
methods. This way a property don't ever have to be redefined in
subclasses if get_x, set_x etc. are changed.
Kay Schluehr wrote:[color=blue]
> Robin Becker wrote:
>
>[color=green]
>>I thought that methods were always overridable.
>>In this case the lookup on the
>>class changes the behaviour of the one and only property.[/color]
>
>
> How can something be made overridable that is actually overridable? I
> didn't know how to better express the broken polymorphism of Pythons
> properties than by stating it as a pleonasm about the used get and set
> methods. This way a property don't ever have to be redefined in
> subclasses if get_x, set_x etc. are changed.
>
> Kay
>[/color]
well I guess that's the ambiguity of human language. Clearly when I
assign to a normal attribute I am changing its value; assigning to a
property or descriptor does something that is not so obvious. Changing
the behaviour of such an attribute could be done by inheritance as
suggested. The new class has overridden the property. When I want to do
that on an instance I have first to create a mutable version of the
descriptor where the mutability is on the instance not the class. I call
the action of changing the base descriptor behaviour 'overriding', but
perhaps that's not the correct word. What do you suggest?
--
Robin Becker
Comment