By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,222 Members | 2,416 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,222 IT Pros & Developers. It's quick & easy.

setters and getters in python 2.6 and 3.0

P: n/a
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?
Nov 29 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
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
Nov 29 '07 #2

P: n/a
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
Nov 29 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.