> > 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 _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
