Bob Ippolito wrote: > > 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 :) > Thanks. > @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. > It seems that writing a decorator is going to be a bizarre experience. In the example, I would need to write a function named 'decoration' that returns a function that will recieve a function (foo) to be decorated and then return a function. Does that sound about right? What would functions like 'decoration' typically look like? Could you show a short code snippet?
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