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

[Bob Ippolito]

On Aug 21, 2004, at 6:15 PM, Paul Morrow wrote:

> 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))) ?

No.

-bob