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

[Phillip J. Eby]

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)))', no matter what the x/y/z expressions 
actually are.  So there are *no* "changes to the Python system" here, just 
a very small amount of syntax sugar.

By contrast, your attribute assignment approach isn't nearly so simple, as 
you will see if you attempt to write an implementation.