Re: [Edu-sig] quantum instance

2005-09-14 Thread Arthur


 -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

2005-09-14 Thread Arthur


 -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

2005-09-14 Thread Scott David Daniels
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

2005-09-14 Thread Dethe Elza
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

2005-09-14 Thread Arthur


 -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

2005-09-14 Thread Kirby Urner
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

2005-09-14 Thread Kirby Urner
 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