@Erik Bray
Ah that’s interesting, thanks for sharing! And again, it’s an additional reason not to fiddle with properties in a class hierarchy if not necessary.

In the end I think class hierarchies are falling out of fashion, and in Python this is particularly true because duck typing is more general than inheritance-based polymorphism… So I guess this is why some mechanisms are not entirely orthogonal with respect to inheritance – in other words nobody cares. That’s fine by me but then again I just wish Pythoners were not so smug in dismissing the use of getters and setters, as there are clearly cases for those…

I guess the answer is to not use super, and instead use the kludgy Foo.foo.fget/Foo.foo.fset.

It’s claimed that data descriptors shouldn’t be overridden by a subclass, but I can’t see what the justification is for that proclamation. There are perfectly good reasons to do this.

Sean mentioned above that you can user super() to access the the property through the base class:

super(Bar, self).foo

This has always worked for me. But interestingly, if I try to override a setter and I do:

@foo.setter
def foo(self, value):
super(Bar, self).foo = value

It explodes with an AttributeError, claiming that the super object has no attribute ‘foo’. I guess this has something to do with super.__setattr__, but I’m not sure. I’d consider this a bug though. Either one should work or neither should work.

this way you don’t need know if the attribute is a property instance

And in your second example, knowing it is a property, you can override the getter with:
class Bar(Foo):
@Foo.foo.getter
def foo( self ):
return super( Bar, self).foo + 1

This works for me in py2.6.5, obviously your article was from some time ago, I am not sure when exactly this became effective.

(Thanks for commenting, I really appreciated it.)

In any case, there are plenty of worse ways that changes to a base class can impact a subclass; subclassing is inherently a tighter coupling between classes than mere use.