Hi All, This has been an interesting and enlightening discussion. I have a bit of knowledge of VPython internals, so I thought I'd jump in here.
Arthur wrote: > >>-----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. Actually, there is some magic going on here. Even at the surface level, setting this attribute has the side effect of changing the appearance of the object on screen. The efficient way to make sure that happens is for the setting of the attribute to actually produce the update. In other words, it actually performs a method call. Beneath the surface, VPython is using a compiled C++ module where these attribute accesses are mapped into C++ getter and setter type methods. > > 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. > I think the point here is that VPython chooses to use the more Pythonic interface allowing the user to "think" about colors (and virtually all other aspects of an visible object) as simple attributes, whereas underneath it is performing method calls. An alternative API would be to simply expose the methods [e.g. mysphere.setColor(color.red)]. In fact, I was first taken aback by VPython's use of what appears to be direct attribute reference. With experience, I have come to appreciate it. The beauty of properties is that it provides an easy and elegant way to provide an attribute-based interface for the client, while allowing the implementer the flexibility to intercept attribute requests through methods. Of course, VPython did this using pre-property techniques. But it's a generally useful thing to do, so making it easy and elegant for the implementer seems to be a rather unambiguous win. Just my $.02 --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA [EMAIL PROTECTED] (319) 352-8360 _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig