On Wed, 25 Feb 2009 15:54:46 -0500, Shawn Milochik <sh...@milochik.com> 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.
Much better practice would be writing unit tests for the behavior you
want. This is a vastly greater measure of protection against future
maintenance introducing bugs than the restrictions you're adding to
your implementation. So if you're looking for good habits to pick up,
start with unit testing. Your test.py files show you're at least
thinking about testing, but you should take a look at something like
the `unittest´ module in the standard library and take things to the
next level.
Jean-Paul
--
http://mail.python.org/mailman/listinfo/python-list
