[Tutor] properties not working in 2.2

karthik Guru karthikg@aztec.soft.net
Tue, 18 Dec 2001 18:56:30 +0530


this is just my observation as a beginner...

i went through the changes in python2.2.
i think many basic things have changed.

I think newbies should learn python using python2.2!.
This is just a recommendation coming from another newbie (that's me).
i think it will be a lot easier to learn that way.

I saw some code in python cook book recipies to emulate properties
plus lots of other things.
I myself experienced the problems associated with __getattr__ ( as to how it
makes recursive calls).
But when i look @ some of the features in python2.2,
i guess we really don't've to be that smart :-)

i saw that now we can write static methods.

may be sometime down the lane we will have keywords like private, protected
and stuff like that as well.

Am not sure how others, who have been doing professional work in python for
years react to this?
Simply put this is my question,

do you guys prefer writing the kind of code presented in the cook book or
are you happy with having a
construct like "property" which makes life so simple?

thanks,
karthik.




-----Original Message-----
From: alan.gauld@bt.com [mailto:alan.gauld@bt.com]
Sent: Tuesday, December 18, 2001 4:57 PM
To: karthikg@aztec.soft.net; glingl@aon.at; tutor@python.org
Subject: RE: [Tutor] properties not working in 2.2


> I have observed such a feature in MS's C# as well.
> Can some one tell from their experience if it's present in
> other languages

Its in VB and also in Delphi.
I'm not sure which did it first but it definitely seems
to come from the Windows world, either via MS or Borland.

In both cases it was originally used to enable
intelligent GUI builders - you can instantiate a
copy of the object when placing it on the form and
set attributes via properties. The property events
can do smart things like display live data in
design mode etc. At least I think thats what they
were first in vented for, my memory is getting hazy
as old age sets in ;-/

In any case it turns out that they are more generally
useful - for example you can define a property which
is a derived field but looks like a fixed field:

### Pseudo code warning ###
class X:
    def __init__(self,min,max):
       self.min b= min
       self.max = max
    def getMean(self): return (self.min-self.max)/2
    property average(self.getMean,None,None, "get average")

x = X(1,5)
print x.min
print x.max
print x.average

So it looks like average is a field of X but in
fact is a return from a method. The same could
be done for max,min and the whole thing could
wrap a database table such that the min,max and
average did a dynamic SQL lookup and returned
the relevant values. But to the client it still
looks like an attribute of the object...

Alan g.