self

[Vojin Jovanovic]

I don't see how that is going to work.  In fact I tried things like that
before without success.  Just sticking the dictionary into eval/exec is
missing the point.  Every time parsing is done flow needs to go through
__getattr__ special method to evaluate nested equations.  Without self. you
can't achieve that effect.  Try the approach you suggested and you'll get
'#U'.


Vin


"Vojin Jovanovic" <vjovanov at stevens-tech.edu> wrote in message
news:TL7L8.79$4p7.4100181 at newnews.cc.stevens-tech.edu...
> > Which of i, j and k are instance variables?  Which are locals?  Which
are
> > globals?  For all its virtues, Python isn't telepathic <wink>.
>
> Well, now that you pointed it out, I think that Python should be
telepathic.
> Those i,j and k variables should have been found in class C, otherwise
they
> should have been searched outside of the class.  I read the FAQ page that
> somebody sent me and I really think that the main reason for self is ...
> "When classes were added to Python, this was (again) the simplest way of
> implementing methods without too many changes to the interpreter. " which
is
> the main and really lousy argument.  All, other arguments are debatable.
>
> Now let me give you the problem with self which is making my life
> complicated. Consider this class.
>
> class Foo:
>  def __init__(self):
>   self.__dict__['Equations']={
>     'a':str(5),
>     'b':'self.a+5',
>     'c':'self.b*self.a'}
>
>  def __getattr__(self,arg):
>   if self.Equations.has_key(arg) == 0:
>    raise AttributeError,  "Foo instance has no attribute '" + arg + "'"
>   try:
>    try:  #first check if this is a simple expression
>     return eval(self.Equations[arg])
>    except:  #if not try to execute it
>     exec self.Equations[arg]
>   except:   #if even that didn't work then just return undefined
>    return '#U'
>
>  def __setattr__(self,arg,val):
>   self.__dict__['Equations'][arg]=str(val)
>
>  def __delattr__(self,arg):
>   del self.__dict__['Equations'][arg]
>
> This class implements a kind of symbolic behavior with the ability to add
> new equations on the fly.  For example...
>
>
> >>> import foo
> >>> A=foo.Foo()
> >>> A.Equations
> {'b': 'self.a+5', 'c': 'self.b*self.a', 'a': '5'}
> >>> A.f='self.b*self.c'
> >>> A.f
> 500
> >>> A.Equations
> {'f': 'self.b*self.c', 'b': 'self.a+5', 'c': 'self.b*self.a', 'a': '5'}
>
>
> As you can see, equations get added on the fly and the parsing gets done
as
> the attribute is being called.  Now, notice that ugly self. thing in the
> equations.  Instead of just typing >>>A.f='a*c' I have to add self in
front
> a and c to achieve the desired effect.  I could not find any other way to
> implement the class in order to avoid typing self. which of course it
> doesn't mean that there isn't any. If anybody has an idea how to do this
> please let me know.  Otherwise, here is the situation where the self
> concept is bad and having such a dynamic language like Python I think
there
> has to be a way out of this problem.
>
> Why is this all relevant? Well, I am working on embedding an interpreted
> language in a large engineering application and Python is  one of few
> candidates.  So I have been looking for its pros and cons.  So far it
passed
> all the tests except the above.  Because, imagine if we required from the
> user of our system that he needs to type self. or even s. in front of
every
> new variable that he has in his equation, it would be a big turn off.
>
> Vin
>
>
>