"Battleship" style game

[J. Cliff Dyer]

On Wed, 2009-02-25 at 15:54 -0500, Shawn Milochik wrote:
> On Wed, Feb 25, 2009 at 3:15 PM, Diez B. Roggisch <deets at 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
>