tweaking @decorator syntax

[Andrew Durdin]

On 5 Aug 2004 16:04:00 -0700, Sandy Norton <sandskyfly at hotmail.com> wrote:
> Here are some more variations.
> 
> Please copy/paste the code below into your favourite python editor and see
> how each syntactical variation of the decorator code reads, and how quickly
> you grok its structure and meaning.

*snip examples*

Of the examples above, I find the "Nested, 'decorate' keyword syntax"
by far the most clear. It has the following features (in no particular
order) which I find attractive:

1. The nesting makes it abundantly clear what the decoration applies
to, namely the function definitions at the next indentation level. And
the colon at the end of the "decorate" line is consistent with all
other Python keywords which result in another indentation level (def,
if, class, etc.) -- which is one reason why I dislike the "nested
@decorator" and "nested |decorator|" options. The "Nested, minimal
decorator syntax" has indentation, but lacks clarity: it appears
merely to be one or a sequence of function calls followed inexplicably
by a nested block.

2. The nesting makes it convenient to apply the same decoration to
multiple functions, which I guess will be fairly common wherever
decorators are used.

3. It doesn't involve adding any additional punctuation to the
language. I strongly believe that the general lack of punctuation
contributes greatly towards Python's readability.

4. The comma-separated list of decorators allows for more compactness
without sacrificing legibility when multiple decorators are used.


Whereas I quite dislike the @ syntax, for almost opposite reasons:

5. In appearance it looks like a special kind of statement; and it is
not at all obvious to me that it is rather a kind of attribute or
modifier of the following function definition. I don't know of any
other construction in Python that performs a similar, unmarked (i.e.
non-explicit) modification of the following statement. So to me the
@syntax comes across as extremely un-Pythonic (by that I mean
radically inconsistent with the conventions of the rest of the
language). For this same reason, I dislike all the proposed syntaxes
which involve placing something before the "def" without a subsequent
indented block.

6. When using the same sets of decorators for multiple
functions/methods in the same module/class, the @ syntax is
inconvenient, as the decorators need to be repeated for each function.
(Of course, the current (2.3) syntax to achieve the same result is
similarly inconvenient; the @ syntax adds no benefit in this regard,
but the "decorate" syntax does).

7. The @ syntax adds more punctuation to Python's syntax: a Bad Thing.
Despite the risk of breaking compatibility with some older programs, I
firmly believe that adding new keywords is a much better idea in
general than adding new punctuation, because (a) keywords are more
readable (especially to those unfamiliar with them), and (b) there is
a very limited supply of punctuation marks on the keyboard, but a very
large supply of words.

8. When using multiple decorators, each appears on a separate line.
This not only confuses things with respect to point 5 above (e.g. does
the first decorator somehow decorate the second, or do both apply to
the function?), but also is IMO unnecessarily lengthy, as each line
has the same basic purpose; In analogy, the latter is similar to the
difference between
    x = 1
    y = 2
    z = 3
and
   x, y, z = 1, 2, 3
where a compact representation is possible and suitable where the
three variables are relating to the same purpose within the program.

-- Andrew Durdin