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