RetroSearch Browse

Tue Aug 3 06:50:56 CEST 2004 · https://mail.python.org/pipermail/python-dev/2004-August/046676.html

James Y Knight wrote:
> 
> [snip]
> 
> 
> 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
> 

   For what it's worth, I agree with James completely.

   Jp

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-August/046676.html below:

[Python-Dev] 2.4a2, and @decorators