Declarative properties

[Dan Stromberg]

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.