At 01:36 AM 8/3/04 -0400, Jp Calderone wrote:
There are clear drawbacks to this approach. Metaclass required, no obvious ways to support free functions, and it depends _slightly_ hackishly on the inspect module. I think at least one of these problems can be solved (and line number handling can be made smarter to deal with intervening comments, whitespace, etc).
But at least *two* of those drawbacks are critical, IMO: the metaclass requirement and the absence of free function support.
What are the advantages?
* It works with Python 2.2 and Python 2.3.
* It requires no interpreter changes. It can be distributed with the standard library, as a cookbook recipe, or in the official documentation as a hint regarding more "advanced" decorator usage.
* It introduces no new syntax and uses up no operator character.
* It supports arbitrary expressions.
* It's pure python.
If those are the only advantages, one might as well use the settrace-based hack, which doesn't have the problems that this one does. Note, by the way, that your 'decorate' function can be implemented by renaming my 'as' function to 'decorate' and dropping the 'decorators.reverse()' line. (i.e. 'as(x,y,z)' is the same as 'decorate(z,y,x)'). Although my examples wrapped such calls in brackets, there's no actual need for them. (Note also that the settrace hack works for class decorations as well as functions.) (FYI: 'as' and 'add_assignment_advisor' are available in the PyProtocols CVS head, in the 'protocols.advice' module.)
I realize there is little or no chance of '@decorator' being pulled from 2.4a2. I hope that something along the lines of the above will be considered, instead, for the next alpha, unless there is widespread community support for '@decorator', as opposed to the ridiculously faint support ("it's better than nothing") currently behind it.
Actually, I'm not sure I agree that it's better than nothing. For one thing, I don't think that there's any ambiguity of interpretation when decorators are written as function calls, be it 'as(classmethod)' or 'decorate(spam)' -- and I doubt that the point was argued at EuroPython, given that Guido missed the thread about it. But... this is moot, since it clearly has been pronounced upon. That pretty much means folks who want decorators right away are left with using the hacks, and not having a syntax-compatible upgrade path. However, that's *still* better than where they were before, because none of the original syntax proposals were expected to be backward-compatible. In practical terms, all this means is that I'll just use the hacked syntax until I no longer need to support Python 2.3.