On Fri, 12 Oct 2007 09:42:28 +0200, Bruno Desthuilliers wrote: >>> So what? Otherwise you carry *always* the baggage of a public >>> property and a private attribute whether you need this or not. At >>> least for me it would be unnecessary in most cases. >> >> That "baggage" of carrying around "unneeded" methods is something the >> computer carries for you - IE, no big deal in 99.99% of all cases. > > 1/ Accessing the value of a property is not free. Accessing a plain > attribute is much cheaper.
Python's current performance characteristics have no bearing on what is good software engineering practice in general, and little bearing on what is good software engineering practice in python. Even from a strictly "what's good for python" perspective, if we limit our view of "good SE practice" to what python can express well right now (and IMO, python can express this fine, but you seem to be arguing it cannot), that needlessly limits python's evolution. I'm not omniscient, and neither is anyone else; when one initially codes a class, one doesn't know to what purposes it will need to be bent in the future; using accessor methods instead of exposed attributes is significantly more flexible for the future of your class. In fact, I may even go so far as to say that public attributes would be good to leave out of future languages that don't have a lot of backward compatibility baggage. It may not be traditional to use accessor methods in python. It may even be a more expensive operation. But neither of these make accessor methods a bad idea in the abstract. > 2/ cluttering the class's namespace with useless names and the source > code with useless code is definitively not a good thing. Adding two clear and flexible methods and eliminating one clear and inflexible attribute is not namespace clutter. It's paydirt. The performance expense in the vast majority of cases is tiny compared to the human expense of going back and fixing a design bug if anything significant has been hinging on your exposed implementation detail. Unless, that is, you don't think your code is important enough to be stretched to another, previously unforeseen purpose someday. If you're coding for a hobby, and enjoy coding for the sake of coding irrespective of how long it takes, rather than as a means to a valuable end, maybe needlessly exposing attributes is a Really Good Idea. My implementation may or may not be lacking (feel free to improve it - in fact, please do!), but that's irrelevant to the heart of the matter, which is "what you didn't think to plan for now most definitely can hurt you later". If you have a program that needs to perform well, you're much better off coding your classes the best way you know how from a Software Engineering perspective, and using pysco or shedskin or pypy or similar to improve performance. If that's not enough, then you're better off profiling the program, and only after that should you recode the critical portions into something like pyrex or a C extension module, or -maybe- some python "tricks". I'd argue that trick-free C or C++ is normally better than python with tricks from a performance vantage -and- from an SE viewpoint. Little hackish tricks for performance's sake scattered throughout a program are very wasteful of something more precious than CPU time. -- http://mail.python.org/mailman/listinfo/python-list
