> Even the problem seems to rather defeat the purpose of a property. A
> property should be very simple - why do you need to override it and
> call super()? Doesn't this rather imply that you've gone beyond the
> normal use of properties *already*?
I'm not sure about that. I'm going to send a USE CASE in a separate
message.
>
> Subclassing and overriding are part of the interface of a class,
> albeit an interface that only a subset of other classes will use.
> Think carefully about why, if this is meant to be made available, it
> isn't simply a method call.
Properties are also part of the class interface. I don't see any good
reason why property get and set methods should not be overridden in
subclasses.
Provisional syntax:
class A:
def __init__(self, prop=0):
self.__prop = prop
@property
def prop(self):
return self.__prop
@prop.setter
def prop(self, value):
self.__prop = value
class B(A):
@super.prop.getter
def prop(self):
print("Getting value",super().prop)
return super().prop
@super.prop.setter
def prop(self, value):
print("Setting new value",value)
super().prop = value
The only problem is that we cannot access "the property setter
implementation of the superclass" easily.
There is already a standard working way to overcome this: property
virtualizer methods. (See my second email.) That pattern *allows
attribute like access and polimorphism at the same time*, but at the
cost of making the class interface more difficult and harder to
understand. I only asked for a way to remove the seemingly neccessary
bolierplate code ("syntax noise") and make it cleaner.
Laszlo
--
https://mail.python.org/mailman/listinfo/python-list
