is decorator the right thing to use?

George Sakkis george.sakkis at
Sat Sep 27 15:23:33 CEST 2008

On Sep 27, 1:44 am, "Dmitry S. Makovey" <dmi... at> wrote:

> George Sakkis wrote:
> > Although this works, the second argument to ProxyMethod shouldn't be
> > necessary, it's semantically redundant;  ideally you would like to
> > write it as "bmethod = ProxyMethod('b')".
> since I'm already on exploratory trail (what about that rug being pulled
> from under....?) With my code I can do really dirty tricks like this (not
> necessary that I'm going to):
> class B_base:
>         def bmethod(self):
>                 print 'B_base'
> class B(B_base):
>         def bmethod(self):
>                 print 'B'
> class A:
>         bmethod=ProxyMethod('b',B_base.bmethod)

Yes, that's indeed dirty; don't do it :)

> > As before, I don't think
> > that's doable without metaclasses (or worse, stack frame hacking).
> > Below is the update of my original recipe; interestingly, it's
> > (slightly) simpler than before:
> Out of curiosity (and trying to understand): why do you insist on
> dictionaries with strings contents ( {'bmethod' : 'b1' } ) rather than
> something more explicit ? Again, I can see that your code is working and I
> can even understand what it's doing, just trying to explore alternatives :)
> I guess my bias is towards more explicit declarations thus
>  bmethod=ProxyMethod('b',B.bmethod)
> looks more attractive to me, but I stand to be corrected/educated why is
> that not the right thing to do?

I see where you're coming from and I also prefer explicit reflection
mechanisms instead of strings (e.g. avoid eval/exec as much as
possible). As I mentioned, the second argument to ProxyMethod is (for
all sane purposes) redundant, so if you could implement it in a way
that "bmethod = ProxyMethod('b')" worked, I would be all for it, but
AFAIK it's not possible without a metaclass. A dict with string keys
and values to be consumed by a metaclass is perhaps the simplest thing
that could possibly work. It contains all the relevant information for
hooking the proxy to the delegate methods and nothing more; zero
boilerplate code overhead. Also note that it's not that big of a
difference; you have to provide the attribute name as a string anyway.

> Another thing that turns me away from string dictionaries is that those are
> the ones causing me more trouble hunting down typos. Maybe it's just "my
> thing" so I'm not going to insist on it. I'm open to arguments against that
> theory.

>From my experience, I am equally prone to typos for both strings and
regular attributes; I agree though that the traceback information is
often more helpful when you mistype an attribute.

> One argument I can bring in defence of more explicit declarations is IDE
> parsing when autocompletion for B.bme... pops up (suggesting bmethod and
> bmethod2) and with 'b':'bmethod' it never happens.

I don't rely on autocompleting IDEs, at least in dynamic languages, so
it's not much of an issue for me but yes, it's another small argument
against strings.


More information about the Python-list mailing list