[Python-Dev] 2.4a2, and @decorators
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 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).
More information about the Python-Dev
mailing list