[Edu-sig] quantum instance

[John Zelle]

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: 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')
>>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
john.zelle at wartburg.edu          (319) 352-8360