lazy arithmetic

[Simon Forman]

pianomaestro at gmail.com wrote:
> Gabriel Genellina wrote:
> > At Friday 25/8/2006 00:36, pianomaestro at gmail.com wrote:
> >
> > ># This is what I have in mind:
> > >
> > >class Item(object):
> > >   def __add__(self, other):
> > >     return Add(self, other)
> >
> > And this works fine... why make thinks complicated?
>
> Yes, I agree it's simpler, and up until now that's the way
> I always did it. Many Many times.
> Now I am looking for a way to build ensembles of these lazy classes at
> the meta-level.
> (think abstract algebra).
>
> > >Item.__add__ = Add
> >
> > This doesn't make sense... __add__ should be a method, not a class...
>
> No, that's not true. It can be this callable:
>
> def add(a, b):
>   return Add(a,b)
> Item.__add__ = add

But that's a function, not a class.  When you assign add to an
attribute of Item it "magically" becomes a method of Item:

|>> add
<function add at 0xb6f3b95c>
|>> Item.__add__
<unbound method Item.add>
|>> x.__add__
<bound method Item.add of <__main__.Item object at 0xb6f3af2c>>

So it works fine.


>
> So my thinking was this: why can't I use a callable class ?
>

When you assign a class to an attibute (be it __add__ or __banana__ or
anything else) the "magic" doesn't take place:

|>> Add
<class '__main__.Add'>
|>> Item.__banana__ = Add
|>> Item.__banana__
<class '__main__.Add'>



> > x+y get translated to x.__add__(y)
>
> No that's not true at all. The self argument to __add__ ends
> up being the Add instance, not the Item instance:

No, that's *exactly* true.  "x+y" does mean "x.__add__(y)" and
"x.__add__"  *is*  the class Add, so you're really calling "Add(y)",
nothing more nor less.

x+y  =>
x.__add__(y)  =>
(x.__add__)(y)  =>
Add(Y)  =>
Hello new Add instance, here's a y for you...  :-)

>
> z=x+y  is translated to z.__add__(y)

Nope.  Just plain wrong.  Not sure why you'd think that.
(No offense intended.)

Peace,
~Simon F.

> 
> Simon.