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

Paul Morrow pm_mon at yahoo.com
Sun Aug 22 00:28:36 CEST 2004

Bob Ippolito wrote:

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.

Ok, I see, nevermind. Thanks.

More information about the Python-Dev mailing list