[Python-Dev] 2.4a2, and @decorators

[Phillip J. Eby]

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.