is decorator the right thing to use?

[Dmitry S. Makovey]

Aaron "Castironpi" Brady wrote:
 
> It might help to tell us the order of events that you want in your
> program.  You're not using 'mymethod' or 'mymethod2', and you probably
> want 'return fnew' for the future.  Something dynamic with __getattr__
> might work.  Any method call to A, that is an A instance, tries to
> look up a method of the same name in the B instance it was initialized
> with.

well 'mymethod' and 'mymethod2' were there just to show that A doesn't
function as a pure proxy - it has methods of it's own. See my respnse to
Steve - I proxy messages to more than one aggregated object. going over
them on __getattr__ to look up methods just doesn't seem to be really
efficient to me (I might be wrong though). Decorators seemed to present
good opportunity to simplify the code (well except for the decorator
function itself :) ), make code bit more "fool-proofed" (and give me the
opportunity to test decorators in real life, he-he).

So decorators inside of B just identify that those methods will be proxied
by A. On one hand from logical standpoint it's kind of weird to tell class
that it is going to be proxied by another class, but declaration would be
real close to original function definition which helps to identify where is
it used.

Note that my decorator doesn't change original function - it's a subversion
of decorator to a certain degree as I'm just hooking into python machinery
to add methods to A upon their declaration in B (or so I think).