Alternative decorator syntax decision

[Nicolas Fleury]

Hi all,

The part of the Python community that doesn't like @decorators needs to 
unite behind an alternative syntax to propose to Guido.  I suggest we 
use this thread to try to do it.  If you agree with @decorators, then I 
suggest you stop reading this message;)

Many syntaxes have been put on http://www.python.org/moin/PythonDecorators.

I suggest to fight the current @descriptors on these two points:
- Less Readable.  The @ character adds a new character with a magical 
sense.  It doesn't read in english as the rest of Python.
- Not Pythonic.  It's a line without a block (like try/finally) that 
affects a following line of code.  It breaks interactive shells.

I suggest that the alternative syntax is both more readable and more 
pythonic.  Many syntaxes have been ruled out by Guido, but he seems to 
be open to a new keyword accessible with a "from __future__ import". 
Since a new keyword would make the syntax more readable (and easier to 
find doc about), so I suggest to discuss these two alternatives, not 
necessarily with these keywords:

Proposal 1:

decorate: staticmethod
def foo(a, b):
     ...

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

other possible keywords: predef, from, as, with

This proposal has basically the advantages of @decorators with a more 
Pythonic approach.  The main drawback is that the decorate block doesn't 
contain anything like normal statements, as with @decorators. 
Implementation already exists.


Proposal 2:

def foo(a,b):
     using staticmethod
     ...

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

other possible keywords: decorate, transform, with, postdef, as

The pool on Wiki suggest that most people would prefer an inside def 
syntax.  It would place decorators at the same place as docstrings, 
which is very Pythonic, since it's consistent with the rest of the 
language.  The main concern is that it places information that can be 
important to callers far from the def.  I guess the answer would be that 
it's not that far from the def and that sometimes the parameters names 
would give strong hints about the decorators.  For example, even if it's 
not forced by the language, a method with a first parameter not named 
self would be strong hint to check the first line of the body to see if 
it's a static method, etc.  I suggest to force descriptors to be before 
the docstring to make them as closer as possible to the def and ease 
finding them.  (Another answer could be that scanning down from the def 
is not that more bad than scanning up from the def).
Is there any implementation existing?

My questions would be: which of these proposals do you prefer to current 
@decorators.  Both?  None?

What keywords would you prefer?  Do you see any that I have not listed?

Do you think there's an alternative that I should have listed, even 
considering what have been ruled out by Guido?

Regards,

Nicolas