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:
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:
Examples
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:
I give two examples that might be common uses in the future. Classmethod declarations, and something like static typing (adapters), declaring what type parameters a function expects and returns.
A. pie decorator syntax
@classmethod
def foo(arg1,arg2):
...
@accepts(int,int)
@returns(float)
def bar(low,high):
...- + Java-like, so not completely unknown to everyone.
- + Makes the syntax obvious visually
- + Will not be silently ignored
- + Compile-time
- + Seperate from the def syntax (desired by some for making decoration stand out and keeping def the same)
- - Seperate from the def syntax (undesired by some for simple decorators like classmethod/staticmethod)
- - Ugly?
- - The @ special character is used in IPython (...)
- - Punctuation-based syntax raises Perlfears.
- - Does not nessecarily
B. list-before-def syntax
[classmethod]
def foo(arg1,arg2):
...
[accepts(int,int), returns(float)]
def bar(low,high):
...- + 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
- - Would not work an interactive mode (list would be interpreted right away)
- 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
C. list-after-def syntax
def foo(arg1,arg2) [classmethod]:
...
def bar(low,high) [accepts(int,int), returns(float)]:
...- + 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?)
D. list at top of function body syntax
def foo(arg1,arg2):
[classmethod]
...
def bar(low,high):
[accepts(int,int), returns(float)]
...- + Also somewhat C#-like
- + Consistent with how docstrings are used.
- + Looks ok for simple or complex decorators
- + Won't break simplistic code analyzers or grep for function def
- + Solves line wrap problem with above proposal
0 There is a hack that implements this now [http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/286147 here].
- - Guido's europython presentation said this didn't win out, but not why
E. pie decorator at top of function body syntax
def foo(arg1,arg2):
@classmethod
...
def bar(low,high):
@accepts(int,int)
@returns(float)
...- Same as above but with pie syntax.
F. inline syntax
def classmethod foo(arg1,arg2):
...
?- + Simple
- + Obviousely attached to the function
- - Does not allow for arguments to the decorator inline, or multiple decorators
- - 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
G. as decorator
as classmethod
def foo(arg1,arg2):
...
?- + 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.
H. with decorator, possibly indented?
with classmethod:
def foo(arg1,arg2):
...
?- + 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