[Python-Dev] Re: Call for defense of @decorators (original) (raw)

Andrew Durdin adurdin at gmail.com
Fri Aug 6 04:46:57 CEST 2004

(This is a repeat of a message on python-list/c.l.p in the "Tweaking @decorator syntax" thread, but I thought it was applicable to post it here, based on how I understand Guido's message. However, this is not a defense but an attack on @decorators, and based not on whether it looks ugly or not but that it is unclear.)

On 5 Aug 2004 16:04:00 -0700, Sandy Norton <sandskyfly at hotmail.com> wrote in c.l.p, thread "Tweaking @decorator syntax":

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:

  1. 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.

  2. 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).

  3. 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.

  4. 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

More information about the Python-Dev mailing list