[Edu-sig] quantum instance
john.zelle at wartburg.edu
Thu Sep 15 16:20:27 CEST 2005
It often seems to me that I agree with you, but you think that you don't
agree with me. This may be one of those cases.
> I'm confused I tell you ;)
> Scott David's Triangle did *not* use a property for area. I think that was
> quite purposeful.
> OTOH, his general explanation for the use case of properties in respect to
> API design seemed to me to be a perfect defense of the extensive use of a
> pattern of:
> def getx(self):
> return self._x
> def sety(self,x)
> self._x =x
> because while now x is a normal attribute you never know what tomorrow may
First up, I don't particularly like the decorator syntax here. However
main concern is (in your words) the use cases for properties. No one is
arguing that you should use use properties anywhere where normal
attribute access suffices. The point is that you can just use the simple
attribute access mechanism if that is what you need now. Later on, if
your design changes, you can use properties so that the API remains
unchanged even though you are now using a method call. Not having to
change the API is good in two ways. First, it means that existing
clients don't break, and second at preserves the simpler user model of
assigning and reading attributes.
This second advantage is one that a desginer might choose to use
up-front. That is, even when an initial design uses a method call, it
might be convenient for users to have an attribute-based API (ala VPython).
> OTOH, as you point out Alex did use exactly your case of the area of a
> Triangle to illustrate properties in Nutshell. Was he simply illustrating
> mechanics or, in so doing, advocating a use case as well?
> Would we have flatted the area method before properties, through the
> __getattr__ mechanism. Were properties put into the language to make it
> more convenient for us to do this kind of thing - *as a way of encouraging
> this kind of pattern*. I think you - implicated or explicitly - think yes.
> I think I explicitly think no.
I don't understand how you can say "no" to this. Properties exist
precisely to make it simpler to call methods through attribute access
syntax, period. My instinct is that, pre-properties, most programmers
would not have resorted to the __getattr__ magic for these simple cases;
they would just provide a method-call API (as I did for my graphics
library). With properties, I would probably now take the other route.
> John and Dethe point out that when a color attribute in vpython is changed
> the proverbial e-mail to Mary needs to be sent - rerender. Before
> properties it was done under the covers, now we have the convenience of
> properties as an alternative. The unambiguous use case, IMO.
> John feels the appearance of properties in the language to be an unambiguous
> win. I would probably agree if I didn't believe it had the side effect of
> having some of us second-guessing the way they did business pre-properties.
Hmmmm. Are you saying adding something to the language that provides a
more elegant way of doing what you were doing before (__getattr__) is a
bad thing? Or are you talking about using properties everywhere you used
to just do attribute reference? The former I don't understand. The
latter I already addressed; don't use a property unless that is what you
> I guess I am pleading for constraint in the presentation of properties to
> novices, with clear *and narrow* use cases.
I can't disagree with this. Beginners don't need properties. Start with
attribute reference. It's important to realize that this would be
anathema in many OO languages (Smalltalk, Java, C++), but it's OK in
Python because it still maintains implementation independence. I used to
be able to guarantee this through __getattr__ and friends. Now it's much
simpler with properties.
> Its part of my campaign for this year's Willison award. I'm think my chances
> are 50/50, best case ;)
Best of luck to you.
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360
More information about the Edu-sig