In my view, the strongest point in favor of a solution that involves calling functions rather than changing syntax is that the functions involved can be placed in the standard library rather than the interpreter.
I believe a widely held view is that features can be supported by the stdlib do not merit language changes?
No viewpoint ought to be held to the exclusion of all others. Using functions with "action-at-a-distance" through sys.settraceback may be okay for an obscure feature that can't be had any other way yet doesn't merit changes to the language, but that's not the situation for decorators. The widely held view here is that decorators need to be added as a syntactic feature to avoid the problems with the postfix notation used in 2.2 and 2.3. Decorators are slated to be an important new language feature and their design needs to be forward-looking, not constrained by what can be implemented in 2.3. One important feature of @deco (and of [deco] prefix as I proposed it) is that it is a compile-time feature. This has all sorts of advantages, since future compilers and tools will be able to know more about methods. Solutions based on sys.settrace fail badly here.
Moreover, I have the impression that many people are clamoring for this feature, no matter how it ends up looking, because they simply *must have it*. Well, if they must have it, why wait for 2.4, when clearly they can have it right now?
Sure, but that's not an argument against improving their situation in 2.4. If I had any hope that something better than @deco was possible but hasn't been discovered yet, I'd be holding off too. But I don't think that's the case. Every solution proposed has its own set of drawbacks, and the drawbacks aren't getting resolved by waiting. --Guido van Rossum (home page: http://www.python.org/~guido/)