• PythonDecorators

Support for decorators was proposed for Python in [http://www.python.org/peps/pep-0318.html PEP 318], and will be implemented in Python 2.4.

What is a decorator

A decorator is a software design pattern. Decorators dynamically alter the functionality of a function, method, or class without having to directly use subclasses or change the source code of the function being decorated.

For more information about the decorator pattern in general, see:

• http://wiki.cs.uiuc.edu/patternStories/DecoratorPattern

• http://en.wikipedia.org/wiki/Decorator_pattern

Debate about decorators in Python

The winning syntax as of now uses the '@' symbol, as described in [http://mail.python.org/pipermail/python-dev/2004-June/045516.html this message]. Mark Russell implemented this version. [http://mail.python.org/pipermail/patches/2004-July/015452.html Here] is the message describing the patch he checked in.

There has been a long discussion about the syntax to use for decorators in Python. See for example these threads:

• http://article.gmane.org/gmane.comp.python.devel/61569

• http://www.livejournal.com/users/jcalderone/3913.html

Examples

   1 @classmethod
   2 def foo (arg1, arg2):
   3     ....

Related Resources

See also: MixIns, MetaClasses

Current Decorator Proposals

After the @decorator syntax was "accepted", lots of people threw up alarms and a huge series of threads started exploding on Python-dev. Here are the current alternatives that I could find that are being argued, with pros and cons:

@decorator "pie decorator syntax" (Before def)

• + Java-like, so not completely unknown to everyone.
• + Makes the syntax obvious visually
• + Will not be silently ignored
• + Compile-time
• - Ugly?
• - Seperate from the def syntax (undesired by some for simple decorators like classmethod/staticmethod)
• - The @ special character is used in IPython (...)
• - Punctuation-based syntax raises Perlfears.
• - Does not nessecarily

[decorator] "list-before-def syntax" (Before def)

• + C# like
• + Can be made backwards compatible-ish, with a "hack"
• + Doesn't cause breakage in existing code-searching tools
• - Doesn't cause breakage in existing code-searching tools

• - EuroPython didn't like it ( why? )

• - The backwards compatability wouldn't be portable to Jython
• - Looks like a normal expression, but has "magic" behavior of altering a function object

def function(arguments) [decorator]: "list-after-def syntax"

• + Also somewhat C#-like
• + Was a "community favorite" at one time
• + Clearly a part of function declaration
• + Looks ok for simple decorators such as classmethod
• + Won't break simplistic code analyzers or grep for function def
• - Long lists of decorators/arguments cause ugly line wraps
• - Guido didn't like (maybe because of line wrap issue?)

def decorator function(arguments) "inline? syntax?"

• + Simple
• + Obviousely attached to the function
• - Does not allow for arguments to the decorator inline.
• - The natural place where everyone looks for the function name now is a possible container for other information
• - Complicates things like colorization and other functions of helper tools

as decorator (Before def)

• + Non-punctuation based
• + Does not use an existing mechanism with 'magic' behavior
• - Guido specifically vetos: "as" means "rename" in too many logical, common places that are in-use, and decorators do not rename.

with decorator (Before def)

• + The benefits of "as" without the renaming oddity.
• + Reads as, "with decorator define function", which seems accurate. Such as, "with staticmethod define foobar(baz)".
• - Adds a new keyword?
• - Guido is reserving "with" for the usage it has in VB, Turbo Pascal, et al