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).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4