Alternative decorator syntax decision
nid_oizo at yahoo.com_removethe_
Fri Aug 20 09:37:12 CEST 2004
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:
def foo(a, b):
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.
def bar(low, high):
using accepts(int, int)
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?
More information about the Python-list