[Python-Dev] Re: metaclass and author are already decorators (original) (raw)

Phillip J. Eby pje at telecommunity.com
Sat Aug 21 23:48:43 CEST 2004

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.

More information about the Python-Dev mailing list