Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

setters and getters in python 2.6 and 3.0

31 views
Skip to first unread message

Daniel Fetchinson

unread,
Nov 29, 2007, 2:13:07 PM11/29/07
to pytho...@python.org
Hi list, I've been following a discussion on a new way of defining
getters and setters on python-dev and just can't understand what the
purpose is. Everybody agreed on the dev list that this is a good idea
so I guess it must be right :)

The whole thing started with this post of Guido:

http://mail.python.org/pipermail/python-dev/2007-October/075057.html

which then continued into November. Basically, the idea is that using
the new way a setter can be added to property that was read-only
before. But if I have this already,

class C:
@property
def attr( self ): return self._attr

what prevents me using the following for adding a setter for attr:

class C:
def attr( self ): return self._attr
def set_attr( self, value ): self._attr = value
attr = property( attr, set_attr )

In other words all I needed to do is delete @property, write the
setter method and add attr = property( attr, set_attr ). What does the
new way improve on this?

Diez B. Roggisch

unread,
Nov 29, 2007, 2:52:28 PM11/29/07
to
Daniel Fetchinson schrieb:

It prevents namespace-pollution in a clever way. By first defining the
getter, the @propset-decorator will augment the already createt property
and return it.

Thus you don't end up with a

set_attr

function.


Other, more complex recipes to do the same look like this and are much
harder to grasp:


@apply
def my_property()
def fget(self):
return self._value
def fset(self, value):
self._value = value
return property(**locals())

So the proposed propset-decorator certainly makes things clearer.

Diez

Daniel Fetchinson

unread,
Nov 29, 2007, 4:36:19 PM11/29/07
to pytho...@python.org

Aaaaaha :)
Makes sense indeed.

Thanks,
Daniel

0 new messages