[Edu-sig] quantum instance

[Arthur]

> -----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.

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