At 11:01 AM 6/25/04 +0100, Armin Rigo wrote:
Hello Phillip,
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 accessible 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 afraid.
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. Among them: * 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: +classmethod +attrs(spam="fidget") def foo(...): ... [classmethod(), attrs(spam="fidget")] def foo(...): ... ~classmethod ~attrs(spam="fidget") def foo(...): ... -classmethod -attrs(spam="fidget") def foo(...): ... 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 themselves. 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.