> The only real necessary restriction on the @ operator is that its > argument be callable and take a single argument. Many expressions > could return a callable object. Why not let them? Is it really worth > having a special case just to SyntaxError expressions that sometimes > won't result in an appropriate callable? > > Things someone might want to do, ordered roughly from most reasonable > to least reasonable ;) > @foo().bar() > @foo or bar > @mydecorators['foo'] > @lambda f: foo(f) or bar(f) > > Why disallow these forms? It seems quite difficult, especially, to > explain why the first one does not, or should not, work. I have a gut feeling about this one. I'm not sure where it comes from, but I have it. It may be that I want the compiler to be able to recognize certain decorators. So while it would be quite easy to change the syntax to @test in the future, I'd like to stick with the more restricted form unless a real use case is presented where allowing @test would increase readability. (@foo().bar() doesn't count because I don't expect you'll ever need that). --Guido van Rossum (home page: http://www.python.org/~guido/)
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