Rather than decorators, how about sections?
Paul McGuire
ptmcg at austin.rr._bogus_.com
Wed Aug 11 13:20:12 EDT 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
names.
-- Paul
More information about the Python-list
mailing list