setters and getters in python 2.6 and 3.0

[Daniel Fetchinson]

> > 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

Aaaaaha :)
Makes sense indeed.

Thanks,
Daniel