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 :) -- http://mail.python.org/mailman/listinfo/python-list
