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