@decorator syntax is sugar, but for what exactly? (decorator libraries).

[Roy Smith]

In article <mailman.1359.1091973019.5135.python-list at python.org>,
 Anthony Baxter <anthonybaxter at gmail.com> wrote:

> > Speaking of libraries, Dan Bishop posted some interesting example of
> > @memoize and @printreturns utility wrappers.  This leads me to think
> > that a good way to leverage the idea of decorators would be a module of
> > common utility functions which could be used as decorators by anybody.
> > I'll call the module martha (since it supplies things used for
> > decorating).  Does the proposed mechanism support something like (to use
> > one of Dan's exmaples, written with two different syntaxen):
> 
> That might happen, but it's unlikely for 2.4. Give people time to use the new
> tools, find out what works well and not so well, and standardise those.

I think you missed the gist of my question, which is probably my fault 
for wrapping it up (decorating it?) with a lot of other peripheral 
points.

The key question is whether the decorator mechanism would allow such a 
thing?  All of the examples I've seen have the decorator defined right 
before it's used, and having a simple name.  I'm guessing that the real 
syntax is @<callable>, and that any expression that evaluations to a 
callable object is kosher after the "@"?  So, any of the following would 
be syntactically correct:

---------------------

import martha
@martha.memoize
def foo (x):
   return x

---------------------

# don't know why you would want to do this, but I'm
# exploring the edges of the envelope.

def decorator1 ():
   pass

def decorator2 ():
   pass

decorators = [decorator1, decorator2]

def getDecorator (i):
   return decorators [i]

@decorators[0]
@getDecorator (1)
def myFunction ():
   pass


---------------------