[Python-Dev] Considering decorator syntax on an individual feature basis

[Martin Zarate]

Issues with decorator syntax.

I think we can all agree that the decorator argument is now wholly a matter of
aesthetic taste, with the brief exception of namespace-based stuff that got
argued when I suggested to use a block instead.

The problem is that we keep jumping from the beginning of the argument to the
end - we keep saying "what syntax do we want" rather than "which syntactic
features do we want".

The features in question, which should be decided individually rather than as a
whole:

- decorator before/within/after def.
Guido is obviously a fan of the "before" approach, and I agree.  The "after" to
me is just ugly, and the "within" (on the same line, I mean) is impractical for
some of the lengthier uses people describe for decorators, although I think that
it is the most "pythonic" in general appearance.

- special character/keyword/no new symbol.
Guido prefers the @ character (I dislike it - it looks meaningless, and it
breaks existing tools - I find it unpythonic).  The "no new symbol" approach
(such as the "list before def", or decorator-after-def-before-name) is often
difficult to parse and, while elegant looking, can make it visually difficult
to distinguish the decorators (and hard to grep).  As such, I prefer the new
keyword statement approach - it is more verbose, but I like it.

- decorator on one/many line(s)
The approach described by the paired-block syntax, and the @ syntax both assume
that users want to include only one decorator per line.  Personally, I am
inclined to follow something like the new import statment wherein the user can
have a comma-delimited list of decorators and can span the list across lines if
they so choose.

- one symbol per decorator vs. one symbol for all decorators
The @ approach has one symbol for each decorator.  The block approach has one
symbol that encompasses all decorators.  If a single symbol is used, then one
must consider whether that symbol occurs on the same line as the decorators or
not.  If not, then the symbol must be brief to avoid letting its repetition be
clumsy.  Personally, I prefer a single use of the symbol, but its really
personal taste.

- indent def/not indent def
If the decorator is before the def, this must be considered.  Indenting the def
is very Pythonic, as it shows the heirarchial relationship visually... but it
also seems an unnecessary indendation in this case, as there is no other case
where an indentation occurs for the benefit of a single statement.

I think if each of these issues could be resolved and agreed to individually,
then a consensis would be far more apparent as to the ideal solution, or at
least some of the myriad solutions could be filtered out.

I think the Python community has mostly settled on a "before def" approach, and
I think that most agree that the @ character is very ugly, but some are coming
around (mostly out of exhaustion though, it sounds).  So if we can agree on the
latter considerations.  Personally, my favourite would be a single-line but
continuable statement (like the "import" statement) which causes the assignment
that occurs on the following line be wrapped by its mentioned objects.  Use a
nice keyword like deco or remake (or even just "be").  Possibly indent the def
one level to show the relationship of the import statement and to allow for def
assignments to look good when used with the statement.

The fact is that there is no Pythonic precedence here - we're talking about a
statement that holds one other statement and has N parameters.  Whenever Python
has had to break into new ground with statements, its been a bit of a mess (take
lambda for example).

Oh, and in defense of "be" as a statement - how's this?

be staticmethod, returning(int), taking(int, bool, bool)
def foo:
    pass

or

be (
    staticmethod,
    synchronised):
foo = lambda: none

but that's just my tastes.  Oh well, I'm violating my own rule, jumping ahead
with a full syntax when we can't even find consensus on the parts of it.