[Python-Dev] 2.4a2, and @decorators

Michael Chermside mcherm at mcherm.com
Tue Aug 3 19:22:42 CEST 2004


James Knight writes:
> 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.


Yeah... what he said.

Seriously, a well-designed programming language has very strong
orthogonality. A few simple concepts should suffice. "an expression"
is an existing production which is well-known to users and well
understood. I agree that using complex expressions in a decorator
leads to difficult-to-read code, but I would STILL like it to be
possible, just so I don't have to remember (or teach) decorators as
a special case.

-- Michael Chermside


More information about the Python-Dev mailing list