Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder2.hal-mli.net!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Wed, 30 Jan 2013 20:12:39 -0500
From: Dave Angel <davea@davea.name>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: confusion with decorators
References: <CAEk9e3ocvL6ikZYv1+sv_DZHdi6NFxW71=ztPcyCH=JVTt_f=g@mail.gmail.com>
In-Reply-To: <CAEk9e3ocvL6ikZYv1+sv_DZHdi6NFxW71=ztPcyCH=JVTt_f=g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1240.1359594784.2939.python-list@python.org>
Lines: 66
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:37975

On 01/30/2013 07:34 PM, Jason Swails wrote:
> Hello,
>
> I was having some trouble understanding decorators and inheritance and all
> that.  This is what I was trying to do:
>
> # untested
> class A(object):
>     def _protector_decorator(fcn):
>        def newfcn(self, *args, **kwargs):
>           return fcn(self, *args, **kwargs)
>        return newfcn
>
>     @_protector_decorator
>     def my_method(self, *args, **kwargs):
>        """ do something here """
>
> class B(A):
>     def _protector_decorator(fcn):
>        def newfcn(self, *args, **kwargs):
>           raise MyException('I do not want B to be able to access the
> protected functions')
>        return newfcn
>
> The goal of all that was to be able to change the behavior of my_method
> inside class B simply by redefining the decorator. Basically, what I want
> is B.my_method() to be decorated by B._protector_decorator, but in the code
> I'm running it's decorated by A._protector_decorator.
>
> I presume this is because once the decorator is applied to my_method in
> class A, A.my_method is immediately bound to the new, 'decorated' function,
> which is subsequently inherited (and not decorated, obviously), by B.
>
> Am I correct here?  My workaround was to simply copy the method from class
> A to class B, after which B._protector_decorator decorated the methods in
> B.  While this doesn't make the use of decorators completely pointless (the
> decorators actually do something in each class, it's just different), it
> does add a bunch of code duplication which I was at one point hopeful to
> avoid.
>
> I'm still stumbling around with decorators a little, but this exercise has
> made them a lot clearer to me.
>
>

I'm certainly not the expert on decorators;  I've only used them for 
simple things.  But I think I can clear up one misconception.

The decorator function will execute while *compiling* the class A, and 
the one in class B is unreferenced.

The decorator @_protector_decorator is shorthand for something like
    mymethod = _protector_decorator(mymethod)

So by the time the compiler ends with class A, the mymethod has its 
final value.

(Note, I've not used a decorator that was defined inside a class, so I'm 
probably missing the appropriate A. or self. or cls. overrides.)
But the order of definition is still correct.  A decorator executes 
once, just after a function is completed.



-- 
DaveA