[Python-Dev] Re: decorators and 2.4

[Phillip J. Eby]

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.