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/pyt...er/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]

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/pyt...er/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

[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/pyt...er/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