[Python-Dev] Call for defense of @decorators

[Phillip J. Eby]

At 10:14 AM 8/5/04 -0700, Guido van Rossum wrote:
>[Phillip]
> > Does this mean that the C#-style syntax has a chance if it's got a
> > __future__?  :)
>
>I don't see how that would change the arguments against it.

I thought the primary argument against it was that it changes the meaning 
of (potentially existing) Python code, and that you had rejected the "hard 
to learn" argument on the basis that people learn by pattern-matching 
rather than principle.

I guess this is another reason to update the PEP...  :)


>No, but I suggest that the proponents of syntax alternatives will have
>to agree amongst themselves on a single alternative that they can
>present to me.

I think that will pretty much guarantee that it's either @ or nothing: it 
appears that the two biggest (or at least most vocal) camps are:

1. people who want a "simpler" syntax that doesn't support arguments (who 
seem to mostly favor 'def classmethod foo()')

2. people who think that decorators without arguments are pointless, and 
don't agree amongst themselves on the proper syntax, but don't necessarily 
care that much as long as there *is* one.  (But there may be a slight 
leaning towards either of the C#-inspired variants.)

Personally, I think the C# list-before-function syntax is, on balance, the 
best of all the choices explored throughout the whole tangled history of 
PEP 318.  It's visually attractive, doesn't *break* the parsing of existing 
tools (that may see '@' as a syntax error), and doesn't interfere with 
grepping for functions.  The "learning" argument was done to death before 
you even invented the syntax: *any* decorator choice results in having to 
learn *something*.

Of course, I suppose that nearly all of these can be turned into opposite 
arguments, for example that '@' causing breakage is a good thing, because 
it means you'll get an error sooner (e.g. if you run the program under an 
older Python).  And round and round the argument goes.  And every so often, 
somebody invents a new syntax, for example:

      foo = classmethod(
          def foo(cls):
              return 42
      )

and then some people love it, and some hate it, and there we go back on the 
merry-go-round.  Sigh.  Just Pronounce on *something* and put us all out of 
your misery already.  :)