is decorator the right thing to use?
Dmitry S. Makovey
dmitry at athabascau.ca
Thu Sep 25 20:22:11 CEST 2008
Aaron "Castironpi" Brady wrote:
> You should write it like this:
> class B(object):
> def bmethod(self,a):
> Making 'proxy' a class method on A.
> In case different A instances (do
> you have more than one BTW?)
yep. I have multiple instances of class A, each one has properties (one per
class) of classes B, C and D:
...magic with proxying methods goes here...
def bmethod(self,x): pass # we proxy this method from A
def bmethod2(self,x): pass # this is not proxied
def cmethod(self,x): pass # we proxy this method from A
def dmethod(self,x): pass # we proxy this method from A
a.bmethod2(x) # raises error as we shouldn't proxy bmethod2
above is the ideal scenario.
> What you've said implies that you only have one B instance, or only
> one per A instance. Is this correct?
yes. as per above code.
> I agree that __setattr__ is the canonical solution to proxy, but you
> have stated that you want each proxied method to be a member in the
> proxy class.
well. kind of. if I can make it transparent to the consumer so that he
As I'm trying to keep b, c and d as private properties and would like to
filter which calls are allowed to those. Plus proxied methods in either one
always expect certain parameters like:
def bmethod(self,c,x): pass
and A encapsulates 'c' already and can fill in that blank automagically:
if not c:
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.
More information about the Python-list