[Python-Dev] 2.4a2, and @decorators

[Phillip J. Eby]

At 07:04 AM 8/3/04 -0700, Guido van Rossum wrote:
> >      Here's a brief test for a syntax-change-less implementation of this
> > feature, not as complete as test_decorators, but a good start, I believe:
>
>[fast forward to syntax example]
>
> >          decorate(staticmethod)
> >          def bar(x):
> >              print x
> >
> >          decorate(classmethod)
> >          def baz(cls, y):
> >              print cls, y
>
>I'm speechless.  If the ambiguous
>
>     [classmethod]
>     def foo(x):
>         ...
>
>is rejected because it doesn't look like it does something to foo, how
>come there's suddenly a crop of solutions that have the same problem
>being proposed?

Because '[foo]' is absolutely a list with no side effects in today's 
Python.  But '[foo()]' clearly *can* have some side effect, so if you're 
reading the code you have to look up 'foo' to understand what's happening 
there.

This isn't at all sudden, btw: David Abrahams made the first 'decorate' 
proposal in June, and suggested the idea of using the debugger hook to 
implement it.  I thought that one of the best parts of David Abrahams' idea 
was that requiring a function call made the [] syntax less ambiguous.


>   What you write looks like a call to the function
>decorate(), followed by a function method definition.  The
>"action-at-a-distance" that is presumed by the decorate() call is
>difficult to explain and a precedent for other worse hacks.

I agree, which is why I wrap my decorators in [], even though it has no 
effect on the actual operation.  It's pure "eye candy" sprinkled with 
syntactic sugar.  :)


>  Its only
>point in favor seems to be that it doesn't use '@'.

Well, the other point is that it allows you to use C# syntax.  Note that if 
it were spelled:

     [classmethod()]
     def foo(x):
         ...

this would also resolve the ambiguity (IMO).