Confused about pep 318

[Steven Bethard]

steven.bethard at gmail.com (Steven Bethard) wrote in message news:<d11dcfba.0408050801.27b5c69d at posting.google.com>...
> 
> Not a big fan of this syntax -- no intuitive reason why @ would mean
> decorator -- but I presume this has already been complained about... 
> Could someone direct me to the discussions about this?  I'd like to
> see why it was the eventual favored syntax...
> 

So, I did my homework and read way too much python-dev for a mere
mortal, and found a good synopsis that is worth looking at if you
haven't already:
    http://www.python.org/moin/PythonDecorators
It gives a bunch of the different considered syntaxes, pros and cons,
etc.

I have to say, after reading the archives and the wiki, I like @ a
little bit more.  The other major frontrunners I saw were a
list-before-def syntax and a function-call-before-def syntax.  Both of
these have the major flaw that they take currently valid Python code
and give it a different meaning.  I don't like that -- it means I have
to relearn part of Python semantics.  Even the list-after-def syntax,
which doesn't introduce semantics changes, isn't substantially clearer
to me as a decorator than @ is -- why is a list before the : a list of
decorators?  Seems almost as arbitrary as @.

What would have seemed most Pythonic to me is a new keyword -- like
was done for 'yield' -- but that seems to have been voted down. 
(Guido especially dislikes the use of 'as' for these purposes.)  I'd
still prefer a new keyword over @, but if a new keyword is out of the
question, I'll take @ over any syntaxes that change Python's current
semantics, and I'll take an implemented and working @ over an as-yet
unimplemented list-after-def syntax.

Steve