Rather than decorators, how about sections?

Paul McGuire ptmcg at austin.rr._bogus_.com
Wed Aug 11 19:20:12 CEST 2004

"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

-- Paul

More information about the Python-list mailing list