[Python-Dev] 2.4a2, and @decorators (original) (raw)

Phillip J. Eby pje at telecommunity.com
Tue Aug 3 16:41:15 CEST 2004

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 testdecorators, 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).

More information about the Python-Dev mailing list