On Aug 2, 2004, at 9:05 PM, Guido van Rossum wrote:
The first patch on SF actually had '@' test, and I requested that it be changed. Most things that are 'test' but not 'dotted_name' optionally followed by an argument list don't make sense as decorators; if you really have a need to write
@ foo or bar def f(): ...
you can write
deco = foo or bar @deco def f(): ...
An even better workaround is to write: def d(arg): return arg @d(foo or bar) def f(): ... However, it seems as if this restriction creates a new class of expression for no gain. It is true enough that *most* python expressions aren't useful to write after a @, but that's also true of a lot of other places an expression can be used (e.g. before a () of a function call. A list comprehension can never result in a callable object. An arithmetic operation usually won't.). 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. James