[Python-ideas] Decorator syntax restriction

[Daniel Fetchinson]

> Can I make another plea for the syntax following '@' to be an unrestricted
> expression?  Guido has said he has a 'gut feeling' against this but has not
> as far as I know rationalised it.
>
> 1) It is inconsistent with Python in general (unPythonic) to impose
> arbitrary restrictions in one particular place, and hard to explain to
> someone learning the language.
>
> 2) The restriction is in any case more apparent than real,
> as
>     @ <any-expression> # disallowed, SyntaxError
> can be implemented, albeit in a more verbose aka less Pythonic was, as:

What makes you think that if something is 'more verbose' it is 'less
pythonic'? I actually like the fact that python doesn't try condensing
everything into one-liners and special symbols.

I never really understood this need for being not verbose, but it does
periodically come up on this list (and pretty much on every other
programming list). Your fingers get tired? It takes too long to read
an extra line? You are running out of space on your harddrive? It
takes too long to transfer the source file over the network because of
the extra line?

Honestly, why do some people set for themselves the goal of "let's
have as few characters in a source file as possible"?

Cheers,
Daniel


>     AnyExpr = <any-expression>
>     @AnyExpr
> or as
>
>     def Identity(x): return x
>      ...
>     @Identity( <any-expression> ) # smuggle in as func arg
>
> 3) I propose the following as plausible use cases (I know other people will
> have their own):
>
> 3.1)
>     @DecoratorList[index]
>
> 3.2)
>     @DecoratorDictionary[key]
>
> 3.3)
>     @Decorator1 if <condition> else Decorator2
> #   Special case of the last one:
>     def Identity(x): return x
>     @Decorator if __debug__ else Identity
>
> Xavier Morel has pointed out that 3.1) can be implemented now as
>     @DecoratorList.__getitem__[index]
> but this doesn't seem a good reason for forbidding the simpler syntax; after
> all Python allows the simpler syntax in other contexts.  Similarly 3.2) can
> be written as
>     @DecoratorDictionary.get(key)
>
> (As an aside, perhaps a decorator that evaluates to None could be treated at
> run-time the same as no decorator, i.e. equivalent to the Identity function
> in the above examples.  Currently it naturally raises TypeError: 'NoneType'
> object is not callable.  Just a thought.)
>
> Finally, sorry if I have not sent this e-mail to the right place (I wanted
> to attach it to the 'allow lambdas as decorators' thread but don't yet know
> how to do this).  Also sorry that this partly duplicates a message I sent to
> python-dev.  I am still finding my way round the Python mailing lists.
>
> Best wishes
> Rob Cliffe


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown