[EMAIL PROTECTED] wrote: > Gabriel Genellina wrote: > > At Friday 25/8/2006 00:36, [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list