While this is nice, I think it somewhat misses the point of Python’s careful syntax debates & decision-making process. Yes, it is good to have the flexibility to do cool stuff (and I'm sure there were ways of getting somewhat decorator-like behavior hacked into Python before decorators), but it's even better when there's a standard, readable, clear way to accomplish whatever cool thing. Then whenever someone needs to do whatever-it-is, they can, easily, and anyone else who comes along will know just what they're doing, and not have to read through whatever code works behind the scenes to make it happen.

IOW, complete flexibility is not the only end goal: adding predictability as well makes the feature twice as nice. There are many possible syntaxes for doing roughly similar things, but if every app uses a different one, life can be hell for whoever has to read the code.

If you read PEP 318, http://www.python.org/dev/peps/pep-0318/, it's easy to see how much thought went into what is syntactic sugar.

I agree. And it's not that Python strictly needed the "@"-syntax in the first place. They just implemented ("hardcoded", as the article calls it) it to make it obvious what is happening.

Gregory Brown recently posted a different take on Decorators using Ruby's delegate standard library.

Worth a look : http://blog.rubybestpractices.com/posts/gregory/008-decorato...