[Python-Dev] Another approach to decorators.

[Brett C.]

Michel Pelletier wrote:

>>Message: 2
>>Date: Tue, 10 Aug 2004 12:55:19 -0400
>>From: Martin Zarate <mzarate at uoguelph.ca>
>>Subject: [Python-Dev] Another approach to decorators.
>>To: python-dev at python.org
>>Message-ID: <1092156919.4118fdf7b71c4 at webmail.uoguelph.ca>
>>Content-Type: text/plain; charset=ISO-8859-1
>>
>>@ means nothing to an uninformed eye.  This violates the most important 
>>feature of Python (imho) which is that it is "runnable pseudocode".  
> 
> 
> Yes!
> 
> 
>>I submit that the most Python solution, that would also be legible (but not 
>>necessarily very pretty) would be to actually make the decorator a bona-fide 
>>block that you nest your class or function into.
>>
>>remake functor(foo, bar), staticmethod:
>>     def baz():
>>           pass
>>
>>This concretely shows the relationship of the original define statement to its 
>>wrapper objects.  The principle is simple - the remake block will close with 
>>only one object in its immediate namespace
> 
> 
> I like your idea a lot, buy why just one?  Your scheme of making decorators a
> block could be applied to several methods in a class:
> 
> class Foo:
> 
>   decorate static:
> 
>     def static1(blah...):
>         pass
> 
>     def static2(blah...):
>         pass
> 
> To me, this idea looks more like Python than all the rest, and allows
> you to consolidate related decorated methods and classes.  Nest them to
> apply decorators "aquisition style":

But then how are you supposed to do multiple decorators for the same method?

I am with Martin that a keyword argument is not going to work here. 
Going that route leads to ``public static 
painInTheAssAndClutteredSyntax(That can) implements Lots, Of, Stuff, 
That throws Things, You, Can, Learn, From, The, Docs`` hell.

-Brett