Bob Ippolito wrote: > > On Aug 21, 2004, at 6:54 PM, Paul Morrow wrote: > >> Bob Ippolito wrote: >> >>> On Aug 21, 2004, at 6:24 PM, Paul Morrow wrote: >>> >>>> >>>> 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? >>> >>> Yes that is correct. >>> >>>> What would functions like 'decoration' typically look like? Could >>>> you show a short code snippet? >>> >>> http://python.org/peps/pep-0318.html >> >> >> Thanks. Of the 5 examples there, the first two are apparently not >> implemented correctly, as they expect that the function/class to be >> decorated is passed directly to them, rather than to the function they >> return. Would you agree? I pasted them here for your consideration... > > > No, they are correct. You are confused. What is expected is that the > result of the expression after @ is callable and takes one parameter. > If the expression after @ is just a name, then nothing particularly > exciting happens at that time. > > @bar # NOTE THE LACK OF PARENTHESES > def foo(): > .... > > is equivalent to: > > _tmp = bar > def foo(): > .... > foo = _tmp(foo) > > _tmp = bar clearly doesn't do anything special > > However, you're confusing that with examples that look more like: > > @bar() # NOTE THE PARENTHESES > def foo(): > .... > > which are equivalent to: > > _tmp = bar() > def foo(): > .... > foo = _tmp(foo) > > -bob Yes, I was missing that. Thanks for the detailed explanation.
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