setters and getters in python 2.6 and 3.0

Diez B. Roggisch deets at nospam.web.de
Thu Nov 29 20:52:28 CET 2007


Daniel Fetchinson schrieb:
> 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?

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



More information about the Python-list mailing list