PythonDecoratorsPoll

This page is just on this wiki temporarily. I hope you don't mind. I put it here because this wiki has the HTML macro enabled which is need to show the voting form.

Python Decorators Poll

I selected what I believe may be the 3 most popular alternatives for the proposed syntax for PythonDecorators. Please read PythonDecorators for more information about these 3 alternatives and then vote in the poll below. Please vote for the one you prefer the most. I tried to answer some questions in advance below. Feel free to add your own comments too.

1. @ before def (A. on the PythonDecorators page) This is the current default choice and there are many who support it.

@classmethod
def foo(arg1,arg2):
    ...

@accepts(int,int)
@returns(float)
def bar(low,high):
    ...

2. list after def (C1.on the PythonDecorators page) This was the community favorite earlier.

def foo(arg1,arg2) [classmethod]:
    ...

def bar(low,high) [accepts(int,int), returns(float)]:
    ...

3. @ at the top of function body (E1 on the PythonDecorators page) This proposal has gained many supporters recently.

def foo(arg1,arg2):
    @classmethod
    ...

def bar(low,high):
    @accepts(int,int)
    @returns(float)
    ...

Voting Form

This poll mainly concerns the position of the decorators: before the def statement, on the same line as the def statement, or at the top of the function body. If you like one of the above syntaxes but prefer a different symbol than @ (such as |), please vote for that syntax any way. You can add your comments here or on the PythonDecorators page.

What's the point? Guido van Rossum has called for us to decide on any alternatives to the "@ before def" syntax. He argued against the two alternatives presented above, but then said again if we can present one or two clear alternatives he would consider them.

If you favor two of the three alternatives but not a third, you might vote for which of the two you prefer the most. If you are against all three, you might either not vote at all or choose the one you hate the least.

Your Comments

Nicolas Fleury - I would have prefer to have at least one proposal that is more readable, using a new keyword. I don't want to be negative, but these 3 proposals share an esoteric syntax that is far less readable than most Python code.

Sundance - Whatever happened to this option?

{{{ def some_function(arg1, arg2) as decorator1, decorator2(blah):

• ..}}}

It had the distinctive and ultimately Pythonic advantage of being immediately readable even without prior knowledge of Python, especially if you allow carriage returns within the decorator declaration. I'll dare to venture that I'm not the only one with a fierce love for Python's readability, right...?

RobinDunn - I like that one too, but I think Guido vetoed it early on for some reason.