[Edu-sig] quantum instance

[Kirby Urner]

> > I don't see you as confused.
> 
> Can't we agree about anything?
> 
> I'm confused I tell you ;)
> 
> Scott David's Triangle did *not* use a property for area. I think that was
> quite purposeful.
> 

I was referring to my Triangle class in 
http://mail.python.org/pipermail/edu-sig/2005-August/005063.html (admittedly
not my first version).  I use properties (for the triangle's angles too),
and area is a property (behind which is getArea).  

I don't use any decorators, though Scott has shown how we might do this by
then.

I wrote:

"It's easy to think of angles and area as attributes, even if we don't allow
them to be set except through changes to edges.  Why should we force a user
to remember what's a method and what's not, given edges, angles and area
(could add perimeter too)."

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

And I say such defensive programming is unnecessary in Python.  You can turn
'x' into a property later, and define new private variable '_x' behind it,
if that's what you need to do.  Plus there's no setter here, only a getter,
so if you wanna go "the whole nine yards" you'll need to go a little further
than above.

> 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?
> 

I don't know about "advocating" a use case.  He's *presenting* a primitive
use case in which making use of the property feature makes sense, is
motivated by the circumstances.  It's like showing how using the cork screw
feature on a Swiss Army knife when you have this bottle of wine and nothing
else handy to open it with.  Does that mean I advocate drinking a lot of
wine?  Maybe, but that's not important here.
 
> 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 think using __getattr__ is comparatively more trouble and maybe more
trouble than it's worth.  The property feature makes such code less
cluttery, requires less hackery and I agree with you that this is in line
with our definition of 'syntactic sugar':  "I think it's fine to call it
"syntactic sugar" when we make object attributes call their associated
accessors and mutators behind the scenes." (same post as linked above).

And although I admire Scott's ability to use decorators in this context (a
better idea than my using them to support differentiation ala calculus), I'm
not myself motivated to use decorators in this way at this time.

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

I don't think the Triangle or Rectangle examples are any less ambiguous.
Better to not have to install the whole VPython library just to find your
first use case, which is implemented in C++ after all (even the color change
part).  But I do agree this is an unambiguous use case (one of many) -- John
was being very apropos in bringing it up.
 
> 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.
> 
> I guess I am pleading for constraint in the presentation of properties to
> novices, with clear *and narrow* use cases.

I think that's fine.  I generally agree with you that Java throws too much
at the novice and gets her into habits of mind *without much justification*
and this is unsatisfying to questioning minds.  Python starts with *far*
less clutter, but the real world rationale for properties (or wine and Swiss
Army knives) hasn't gone away.  They still turn out to be useful, as do
other design patterns the Java books go on about.
 
> Its part of my campaign for this year's Willison award. I'm think my
> chances are 50/50, best case ;)
> 
> Art

Things we agree on:  too much up front clutter is bad, Java has too much up
front clutter, CS would do well to import math and geometry as grist for its
mill, to illustrate new mechanics based on use cases.  Plus I think kids
learning math need more Swiss Army knives like Python.

Kirby