On Mon, 2005-10-17 at 22:24, Guido van Rossum wrote: > > IMO, there's not enough advantage in having the property() call before > > the functions than after. > > Maybe you didn't see the use case that Greg had in mind? He wants to > be able to override the getter and/or setter in a subclass, without > changing the docstring or having to repeat the property() call. That > requires us to do a late binding lookup based on a string.
True, I missed that use case. But can't you already support
override-ability just by refactoring the getter and setter into separate
methods? IOW, the getter and setter isn't overridden, but they call
other methods that implement the core functionality and that /are/
overridden. Okay, that means a few extra methods per property, but that
still doesn't seem too bad.
> If you can think of a solution that looks better than mine, you're a genius.
Oh, I know that's not the case, but it's such a tempting challenge, I'll
try anyway :).
class A(object):
def __init__(self):
self._x = 0
def set_x(self, x):
self._set_x(x)
def _set_x(self, x):
print 'A._set_x()'
self._x = x
def get_x(self):
return self._get_x()
def _get_x(self):
print 'A._get_x()'
return self._x
x = property(get_x, set_x)
class B(A):
def _set_x(self, x):
print 'B._set_x()'
super(B, self)._set_x(x)
def _get_x(self):
print 'B._get_x()'
return super(B, self)._get_x()
a = A()
b = B()
a.x = 7
b.x = 9
print a.x
print b.x
Basically A.get_x() and A.set_x() are just wrappers to make the property
machinery work the way you want.
-Barry
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
