Re: [Edu-sig] quantum instance
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dethe Elza As Guido has said, properties don't do anything that couldn't be done before with __getattr__ and __setattr__, they just give a cleaner syntax for it. Since VPython makes extensive use of __getattr__ and __setattr__, do you think you would like the package more or less if they used properties instead? Or perhaps if instead of (I don't actually remember if VPython allows named colours, but bear with me for this example): ball = sphere(color=blue) # a blue sphere appears on the screen ball.color = 'red' # the ball changes instantly to red would this be better if we wrote: ball = sphere(color='blue') ball.setColor('red') does that make it more readable, or less? What are you saying here? ball.color='red' is what is readable. Why is the color attribute of the sphere anything other than a normal Python attribute initialized by a keyword argument, with some default? It is set and retrieved. No magic. Are you suggesting that since normal attribute mechanics use __getattr__ and __setattr__ under the hood, my issue with the use cases of properties are somehow an issue with Python's entire attribute mechanism. If so you have indeed joined the debate, as such ;) If vpython has some implementation specific reason to need to send an e-mail to Mary when I change the color attribute, I may in fact have a preference for the use of __setattr__ directly, as more expressive of the fact that we are under the hood a bit - but that admittedly can get ugly and the truth is I would probably myself opt for the convenience of property, maybe going the whole nine yards and using the further convenience of its decorator form. If I were sending an e-mail to Mary. Art I didn't get a harrumph out of that guy Mayor, Blazing Saddles ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
-Original Message- From: [EMAIL PROTECTED] [mailto:edu-sig- [EMAIL PROTECTED] On Behalf Of Arthur the whole nine yards and using the further convenience of its decorator form. Oops. Forgot. Can't use @property for a set. Because of course @property is itself in some sense an accident of history. Dying to share all this in Python 101. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
Arthur wrote: ... But I still don't see the connection to XP programming, API design Do you truly not understand my position, or merely disagree with it? --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
Thanks John, you set what I meant. On 14-Sep-05, at 8:21 AM, Arthur wrote: Oops. Forgot. Can't use @property for a set. Because of course @property is itself in some sense an accident of history. Not so much an accident of history: property was never intended as a decorator and probably shouldn't be used as one. If you really want to create a read-only decorator, make a new one called readonly or some such. You can still *implement* it with property, of course. Dying to share all this in Python 101. Not every part of the language needs to fit into an introduction. There are obscure parts of English that not everyone uses day to day, but that doesn't mean I argue with poets who use them. --Dethe I started with nothing, and I still have most of it. -- Steven Wright ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dethe Elza Not every part of the language needs to fit into an introduction. There are obscure parts of English that not everyone uses day to day, but that doesn't mean I argue with poets who use them. This started with a Triangle class. It has 3 sides, And an area. 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. If you want to see me as a confused student - you're welcome. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
Art: I would probably myself opt for the convenience of property, maybe going the whole nine yards and using the further convenience of its decorator form. Footnote: Although I think Scott did an admirable job of showing how the property function could be served with the new decorator syntax, I don't think the trade off in convenience is necessarily worth the convoluted helper functions that make this short-cut doable. That being said, I'm quite pleased that Scott spelled it out, and I have in fact used his invention (in subsequent code). In yet more recent code (satacad.py with Vector, Edge and Polyhedron classes), I'm back to straight attr = property(args) syntax, and quite satisfied with it. I feel no strong temptation to use decorators in this context. In sum, I wouldn't necessarily go the whole nine yards as you've put it. Kirby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
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