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 point of using property() is that you can start out using attribute access on its own (which is the standard Python way to do things: getters and setters are seen by most as redundant code).
Once you need programmed access on read and/or write, leave the client code (the code that accesses the attributes) as it is, but turn the attributes into properties so that the functions are invoked automatically on attribute-style access. So I believe what Diez was saying is that by using properties in your existing code you are getting the worst of both worlds - unnecessarily complex objects, and code that uses those objects by calling methods when it could be accessing attributes (or properties - depending on the implementation). At least this is true of your Ship test code. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list