[Edu-sig] quantum instance

[John Zelle]

Arthur,

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.

Arthur wrote:
> 
>>-----Original Message-----

> 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:
> 
> @property
> def getx(self):
>    return self._x
> 
> @porperty
> def sety(self,x)
>    self._x =x
> 
> because while now x is a normal attribute you never know what tomorrow may
> bring.

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 
need.

> 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