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