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))) ?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4