On Wed, 2009-02-25 at 15:54 -0500, Shawn Milochik wrote:
> On Wed, Feb 25, 2009 at 3:15 PM, Diez B. Roggisch <de...@nospam.web.de> wrote:
>
> > Not really. The point about properties is that you *can* make attribute
> > access trigger getter or setter code.
> >
> > But not that you do unless there is an actual reason for that. The way you
> > do it now is simply introducing clutter, without benefit. Your class would
> > be half the current size - without loss of functionality.
> >
> >
> >
> > Diez
> > --
> > http://mail.python.org/mailman/listinfo/python-list
> >
>
> It is true that it would be fewer lines of code with the same
> functionality, but it's better practice to have that framework in
> place so that any changes made in the future wouldn't break any of the
> code accessing my class. Obviously this is a fairly simple game that
> has a fixed set of rules, but I'm trying to cultivate good habits, and
> I don't think that doing it this way is anti-Pythonic.
>
> Unless, of course, anything I said is wrong, which is always possible.
> If I'm missing a bigger-picture idea, I'd like to know about it.
>
The piece you're missing is exactly why properties are so cool.
They take what looks like attribute access from the client side, and
pass it through a method. So while you can add any sort of changes you
want to make can be made without breaking any client code. To them, it
still looks like attribute access.
class Foo(object):
a = 4
class Bar(object):
def __init__(self):
self._a = 4
def _get_a(self):
return self._a
def _set_a(self, value):
if not value % 2:
self._a = value
a = property(_get_a, _set_a)
>>> foo = Foo()
>>> foo.a
4
>>> foo.a = 5
>>> foo.a
5
>>> bar = Bar()
>>> bar.a
4
>>> bar.a = 5
>>> bar.a
4
>>> bar.a = 6
>>> bar.a
6
> Thanks,
> Shawn
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
