[Python-Dev] 2.4a2, and @decorators (original) (raw)

James Y Knight foom at fuhm.net
Tue Aug 3 06:17:43 CEST 2004

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 'dottedname' 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

More information about the Python-Dev mailing list