is decorator the right thing to use?

[Dmitry S. Makovey]

Aaron "Castironpi" Brady wrote:
>> I kept this part of the problem out of this discussion as I'm pretty sure
>> I can fill those in once I figure out the basic problem of
>> auto-population of proxy methods since for each class/method those are
>> going to be nearly identical. If I can autogenerate those on-the-fly I'm
>> pretty sure I can add some extra-logic to them as well including
>> signature change where A::bmethod(self,c,x) would become
>> A::bmethod(self,x) etc.
> 
> Do you want to couple instances or classes together?

It would be nice to have objects of B, C and D classes not knowing that they
are proxied (as they are used on their own too, not only inside of A
objects). 

> If A always proxies for B, C, and D, then the wrapper solution isn't
> bad. 

the whole purpose of A is pretty much to proxy and filter. It's got some
extra logic to combine and manipulate b, c and d objects inside of A class
objects.

> If you're going to be doing any instance magic, that can change 
> the solution a little bit.
> 
> There's also a revision of the first implementation of Aproxy you
> posted, which could stand alone as you have it, or work as a
> classmethod or staticmethod.
> 
> def Aproxy(fn):
>     def delegate(self,*args,**kw):
>         print "%s::%s" % (args[0].__class__.__name__,fn.__name__)
>         fnew=getattr(self.b,fn.__name__)
>         return fnew(*args,**kw)
>     setattr(A,fn.__name__,delegate)
>     return fn

yep, that does look nicer/cleaner :)