[Python-Dev] Re: decorators and 2.4
Phillip J. Eby
pje at telecommunity.com
Fri Jun 25 16:09:19 EDT 2004
At 11:01 AM 6/25/04 +0100, Armin Rigo wrote:
>On Fri, Jun 25, 2004 at 01:27:03AM -0400, Phillip J. Eby wrote:
> > About the only bit you couldn't do in pure Python would be decorating a
> > function defined in a nested scope, because "fast locals" aren't
> > from pure Python.
>Would you believe it? Your implementation works just fine in this case too
>:-) sysmodule.c invokes PyFrame_FastToLocals and PyFrame_LocalsToFast around
>a call to a trace function, so that any change to f_locals from the trace
>function are actually correctly reflected into the frame.
Wow. You're right, it does work. The time machine strikes again. :)
>Excellent. Let's put this in the standard library and close the issue ;-)
Ah, if only that *would* close the issue. It really just opens more, I'm
>As an easy extension, decorate(attr=value, ...) could just assign attributes
>to the function object. Also, the fact that it works with other assignment
>statements is a bonus in my opinion, e.g.:
See, I told you it opens more issues.
* The location in the stdlib of 'decorate'
* The signature of 'decorate', including whether it should even be *called*
'decorate', or something else.
* Whether to have a 'decorate' function at all, or whether it's better to
just list specialized decorator objects/functions (I generally favor the
latter, since 'decorate' is IMO a dead chicken that hasn't appeared in any
widely-supported syntax proposals to date).
* Which of the numerous possible syntax variations should be used/recommended:
All of these are possible, and each likely to have *some*
proponents. Oh, and let's not forget the question of application order of
the decorations. :) I personally favor a(b(c(...))) ordering for
decorations that are listed before the 'def', even though I favor a(), b(),
c() ordering for decorations that come after.
Anyway, I think it's probably more realistic to say that the presence of a
viable implementation approach that allows numerous policies and syntax
variants to be experimented with, even in existing Python versions, means
it's more likely that Guido will *not* allow this in the stdlib for 2.4,
and leave it for the frameworks that need this to fight it out amongst
I'm not sure if this is good or bad. Personally, I'd prefer Guido to
"bless" one of the above syntax alternatives as the recommended way to do
these things, along with a "blessed" order in which decorators should be
applied. Then, in any of my frameworks that I implement this for, I'll be
able to be "forward compatible" with other frameworks that do the same.
By the way, I should also mention that I think with this approach, my
strongest objection to Guido's original syntax proposal goes away: if you
have to *call* the decorators, it makes it more obvious that something is
happening. When you could just list '[classmethod]', it's not obvious that
that line *does* anything. If you have '[classmethod()]', it's apparent
that something is being invoked.
More information about the Python-Dev