The benefit of properties (was Re: PEP 8: on member variables vs. attributes)

Donn Cave donn at u.washington.edu
Fri Jan 17 12:52:20 EST 2003


Quoth Laura Creighton <lac at strakt.com>:
| Peter Hansen wrote:
|> 
|> I rebelled against this at the time, almost outlawing properties,
|> because it got to the point where I couldn't tell when something
|> was just setting a value, possibly with a check or clipping or
|> something applied, and when the code -- which looked like a simple
|> assignment -- was actually storing some data in a file, sending
|> a message to another thread, stopping the machine's motion, and 
|> then launching a Space Shuttle.
|> 
|> No doubt forbidding them was an overreaction, but at least it
|> let us start getting a handle on the complexity of the code.
|
|> I've been looking forward to having a chance to let them redeem
|> themselves when I start using them with Python... if they can.
|> Do they really enhance clarity and maintenance, or might they be
|> more _in the way_ of easy comprehension?
|
| This is a judgement call based on what level of abstaction you want
| for the solving of your problem.  Do you want any of your programmers
| to _care_ that what really happens when a state changes is 'store some
| data in a file, send a message to another thread ....'?  If their
| reaction is 'we're mathematicians, don't talk to us about hardware'
| then they may be absolutely correct.

Maybe it's because my programming career has never taken me into
the rarified world of large projects with an organized collaborative
structure like that, but I'm getting the feeling that my model of
programming is different than yours.

In my world, everyone who deals with code is eventually liable to care
how it works.  Especially with regard to state changes or side effects.
Not so much because we're itching to exploit this knowledge for evil
violations of one kind or another, more because it's eventually the only
way to understand why it works the way it does.  (Note ``eventually'',
I'm speaking of a last resort but a common one.)  We can't afford to
make code opaque to anyone.

Python's notation and the ``consenting adults'' attitude help make code
more reliably understandable, for users and I think even for its authors.
That used to be one of the attractions of Python.  I'm sure that there
are other ways to live where that wouldn't be such a big concern, but
of course there are many other programming languages too.

	Donn Cave, donn at u.washington.edu




More information about the Python-list mailing list