Rather than decorators, how about sections?

[Paul Morrow]

Paul McGuire wrote:
> "Paul Morrow" <pm_mon at yahoo.com> wrote in message
> news:mailman.1509.1092238688.5135.python-list at python.org...
> 
>>I like many am not wild about the <at> operator.  I also don't think
>>that the decorator syntax should be so directly attached to the method,
>>since what we're trying to do is to say something about the
>>*relationship between* a method and a class (e.g. "method m is a
>>staticmethod of class C").
>>
>>So if we are going to extend the Python grammar to support this sort of
>>thing (which I believe is a good idea), my preference would be to
>>introduce named sections within a class definition, such as...
>>
>>     class Foo(object):
>>         staticmethods:
>>             def baz(a,b):
>>                 print "I'm a static method."
>>             def bez(c,d):
>>                 print "I'm a static method too."
>>
>>         classmethods:
>>             def biz(klass):
>>                 print "I'm a class method."
>>
>>
>>         def __init__(self):
>>             print "We all know what I am."
>>
> 
> This only addresses the "decoration" for declaring static and class methods.
> The decorator mechanism is intended to include much more than this simple
> class declaration feature.  See
> http://www.python.org/cgi-bin/moinmoin/PythonDecoratorLibrary for the first
> application (memoize - a return value cacheing helper/decorator, to optimize
> access to repetitive or compute-intensive function calls, with NO changes
> needed to the function itself).  Other decorator candidates I've seen
> mentioned are:
> - mutex lock/unlock wrapper
> - debugging/logging wrapper
> - pre-condition/post-condition assertion wrappers
> - input argument validation/typing wrapper
> - return value type validation wrapper
> 
> For this degree of flexibility, you can't hard-wire in specific section
> names.
> 
> -- Paul
> 
> 

I agree.  My proposal wasn't looking at the bigger picture here.  But 
see the post by Stepfan Eischet in this thread.  It doesn't address all 
of those issues either, but it does make the bigger problem smaller, by 
using an obvious interpretation of the method arguments to infer the 
type of method (i.e. class -versus- static -versus- instance).  By using 
this simple convention (that most everyone is probably using already), 
that aspect of the annotations require no additional syntax.

Hmmm... did I say 'aspect'?  Maybe instead of cluttering up the code 
with all of these 'declarations' (which is clearly where the decoration 
movement is headed), we should have some sort of companion file that 
contains these annotations, similar to what you see in the AOP languages.