On Aug 21, 2004, at 5:34 PM, 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. > > def foo(whatever): > __decoration__ = (1,1,param=True) > > def decoration(decoratedFunc, a, b, param=False): > __decorator__ = True > __version__ = '0.1' > # body of 'decoration' decorator function goes here... Congratulations, this by far the worst suggestion yet! I'm -Inf on this :) @decoration(1,1,param=True) makes no changes whatsoever to the Python system. Everything after the @ is really just an expression. The @ just implies that the result of the next class or def gets put through the result of the @expression before it is thrown into the namespace. -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