[Edu-sig] quantum instance
john.zelle at wartburg.edu
Wed Sep 14 16:57:01 CEST 2005
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.
>>From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] 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')
>>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 M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360
More information about the Edu-sig