> This started with a Triangle class.
>
> It has 3 sides,
>
It had 3 sides that I made open to rebinding, such that mytri.a = 6 could be
used to change the shape of the triangle at run time, ergo its area -- which
is why I wanted to see area as both an attribute (makes sense) and a
read-only one at that (because rebinding area could mean any number of side
combinations -- too impractical for my current needs).
> And an area.
>
The area gets to come off as an attribute, as in mytri.area, but it's
triggering a method, cuz my user may have changed one of the sides in the
meantime. I don't recompute area until I have to (or my Triangle doesn't,
whatever).
> And I have made the most excellent point about confusing students by not
> being clear about whether one is explaining mechanics and or illustrating
> a use case.
>
I think I was clear: the use case of implementing a Triangle class with
modifiable edges drives home the point of syntax like property. And as I
mentioned at the time, Alex Martelli gives a similar use case regarding the
Rectangle ('Python in a Nutshell'). In both cases, I think the use case
gives a good example of why we might want to use such syntax (I'm not saying
anything about decorators -- a whole different discussion).
If by mechanics you mean syntax (and underlying implementation) then I think
here we have geometry providing grist for the CS mill (as you said we should
do, and as I agreed we should). Math feeds CS with examples, and CS
provides math with machine-executable notations -- a two way street of great
pedagogical value.
> If you want to see me as a confused student - you're welcome.
>
> Art
I don't see you as confused. But I don't see me as confused either. The
examples were clear, the mechanics are clear. All that remains are
differences in judgment as to whether this or that other use case merits
using the property feature. Sometimes, using properties is as bad an idea
as it is a good one, in other contexts, especially in Python, which doesn't
penalize so heavily if you decide to change your design later (so don't
clutter your code just because "you'll wish you had someday").
Kirby
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
