[Python-Dev] Re: __metaclass__ and __author__ are already decorators

[Paul Morrow]

Phillip J. Eby wrote:

> At 05:34 PM 8/21/04 -0400, Paul Morrow wrote:
> 
>> Phillip J. Eby wrote:
>>
>>> At 05:15 PM 8/21/04 -0400, Paul Morrow wrote:
>>>
>>>> Christophe Cavalaria wrote:
>>>>
>>>>> can it be ? There's also the fact that it can't handle named 
>>>>> parameters
>>>>> like a regular function call. You can't write that :
>>>>> def foo():
>>>>>     __decoration__ = (1,1,param=True)
>>>>
>>>>
>>>>
>>>> As far as I know, we can't do that with the current decorator 
>>>> proposals either.
>>>
>>>
>>> @decoration(1,1,param=True)
>>> def foo(whatever):
>>>     pass
>>
>>
>> Ok, then whatever changes you've made to the Python system to support 
>> that would allow the same syntax to be used in what I'm suggesting.
> 
> 
> Huh?  @decoration(1,1,param=True) is evaluated at the place where it 
> appears.  The *return value* of that expression is then called, passing 
> in the foo function.  In other words, the above is equivalent to today's:
> 
>     def foo(whatever):
>         pass
> 
>     foo = decoration(1,1,param=True)(foo)
> 
> except that the first assignment to 'foo' doesn't happen, only the 
> second one.  If the 'foo' function is a single expression, of course, 
> today you can do the straightforward:
> 
>     foo = decoration(1,1,param=True)(lambda whatever: something)
> 
> So, "@x func" is effectively a macro for "func = x(func)", where 'func' 
> may be a function, or another decorator.  That is:
> 
>     @x
>     @y
>     @z
>     def foo():
>         ...
> 
> is shorthand for 'foo = x(y(z(foo)))', 

Wouldn't that actually be shorthand for foo = x()(y()(z()(foo))) ?