On Wed, Oct 19, 2011 at 11:43 PM, Chris Rebert wrote:

<snip>

...

Is there something obvious I am missing, or is there a weird thing in the way decoratirs are parsed ?

PEP 318 -- Decorators for Functions and Methods (http://www.python.org/dev/peps/pep-0318/ ): "Current Syntax [...] The decorator statement is limited in what it can accept -- arbitrary expressions will not work. Guido preferred this because of a gut feeling [17]." [17]: http://mail.python.org/pipermail/python-dev/2004-August/046711.html

According to Python 2.7's grammar (http://docs.python.org/reference/grammar.html ):    decorator: '@' dotted_name [ '(' [arglist] ')' ] NEWLINE    dotted_name: NAME ('.' NAME)*

So, you're limited to an arbitrarily-long sequence of attribute accesses, followed by an optional call.

Thanks for the pointers

Cheers, Chris -- http://rebertia.com

-- Tarek Ziadé | http://ziade.org

On Wed, Oct 19, 2011 at 3:36 PM, Nick Coghlan wrote:

On Thu, Oct 20, 2011 at 7:52 AM, Tarek Ziadé wrote:

...

...

So, you're limited to an arbitrarily-long sequence of attribute accesses, followed by an optional call.

Thanks for the pointers

In the time since, Guido gave his approval to removing the restriction, but nobody has been interested enough to actually implement the change. He was persuaded the restriction was pointless largely due to people using tricks like the following to avoid it:

def deco(x):    return x

@deco(anything[I].like().can.go[here].and_the.compiler.will_not(care)) def f():    pass

(There were also legitimate use cases related to looking up decorators via a subscript rather than a function call).

If this gets changed we won't be able to give a different meaning to e.g. @(...) @[...] @{...} since those will all have to be accepted as valid forms of the syntax @<expr> -- --Guido van Rossum (python.org/~guido)

2011/10/19 Nick Coghlan :

2011/10/20 Guido van Rossum :

...

If this gets changed we won't be able to give a different meaning to e.g.

@(...) @[...] @{...}

since those will all have to be accepted as valid forms of the syntax

@<expr>

True, although the restriction could just be weakened to "must start with an identifier" rather than eliminated entirely. Since tuples, lists, dictionaries and sets aren't callable, that wouldn't be a noticeable restriction in practice.

But surely someone would manage to come up with a use case for an expression *starting* with one of those, e.g. @[f, g, h][i] or @{a: b, c: d}[x] I don't think it's reasonable to constrain it less than it currently is but more than a general expression. Though I wouldn't allow commas -- there's no way that @f, g def pooh(): ... can make sense. Oh way, it could be a shorthand for @f @g def pooh(): ... :-) -- --Guido van Rossum (python.org/~guido)