Decorator Base Class: Needs improvement.

[Ron_Adam]

On Tue, 05 Apr 2005 14:32:59 -0700, Scott David Daniels
<Scott.Daniels at Acm.Org> wrote:

>Ron_Adam wrote:
>> What I was referring to is the case:
>>     @decorator(x,y,z) 
>> As being a decorator expression with more than one argument.  
>But, we generally say this is a call to a function named decorator
>that returns a decorator.  If you called it:
>     @make_decorator(x,y)
>     def .....
>We'd be sure we were all on the same page.

Good point, I agree. :)

Or alternatively 
	@call_decorator(x,y)

Using either one would be good practice.

>How about this as an example:
>
>     def tweakdoc(name):
>         def decorator(function):
>	    function.__doc__ = 'Tweak(%s) %r' % (name, function.__doc__)
>	    return function
>         return decorator
>
>What is confusing us about what you write is that you are referring to
>tweakdoc as a decorator, when it is a function returning a decorator.

Bengt Richter is also pointing out there is an inconsistency in
Pythons documents in the use of decorator.  I've been trying to start
referring to the "@___" as the decorator-exression, but that still
doesn't quite describe what it does either.  Decorarator-caller might
be better. Then the decorator-function as the part that defines the
decorated-function.

Another alternative is to call the entire process what it is,
function-wrapping. Then the "@____" statement would be the
wrapper-caller, which calls the wrapper-function, which defines the
wrapped-function. That's much more descriptive to me.

If we do that then we could agree to use decorator as a general term
to describe a function as decorated. Meaning it is wrapped and get
away from the decorator/decoratoree discussions. But I think that the
terminology has been hashed out quite a bit before, so I don't expect
it to change.  I'll just have to try to be clearer in how I discuss
it.

>> and not: 
>>     @decorator(x)(y)
>
>This is only prevented by syntax (probably a good idea, otherwise
>we would see some very complicated expressions before function
>declarations).
>
>--Scott David Daniels
>Scott.Daniels at Acm.Org

And this isn't allowed either, although it represents more closely the
nesting that takes place when decorator-expressions are stacked.

@make_deco1
    @make_deco2
        @make_deco3
            def function1(n):
                n+=1
                return n


This is allowed, but its not pretty.

@make_deco1
@    make_deco2
@        make_deco3
def function1(n):
     n+=1
     return n


Cheers,
Ron