elements of decorator syntax suggestions

[Anthony Baxter]

This is an excellent list! Thanks for doing it. I've made a couple of notes
inline about the particular points.

On 6 Aug 2004 10:19:21 -0700, Steven Bethard <steven.bethard at gmail.com> wrote:
> I think one of the biggest reasons we're having such problems coming
> to any agreement on decorator syntax is that each proposal makes a
> number of syntax decisions, not just one.  For decorators, I see the
> following decisions that must be made:
> 
> 1) Indicator
> Proposals differ on how some sort of indicator of "decoratorhood" is
> use.  These include:
> * none (e.g. just the list, as in the "list-after-def" suggestion)
> * the '@' character
> * a new keyword (with, using, decorate, etc.)

This is the biggy, it seems. Current (as of a couple of hours ago) 
discussions on python-dev are discussing other alternatives instead
of @, that will hopefully make it easier for IPython or Leo to cope 
for now (but note that in the future, some other use for @ might be
found, so anyone relying on it at the moment might want to think 
about that). One current suggestion is to use the | character, instead.

> 2) Location
> Proposals also differ on exactly where the decorator declaration
> should be made.  These include:
> * before def

Short of someone producing a _very_ strong argument in favour of
another form, this is almost certainly going to be the choice.

> * between def and function name

Breaks too many tools, as well as stupid humans who are used to seeing
def functionname.

> * between function name and argument list

I'm not sure that this was ever popular, with anyone ;)

> * between argument list and colon

Guido's ruled this out (see previous posts, I put a link to his post
outlining why.

> * after colon (first line in body)

A problem here is interaction with docstrings?


> 3) List notation
> As I understand it, it's already decided that any implementation of
> decorators must allow for a list of decorators to be applied.  So
> proposals that might be accepted must explain how this can be done.
> The options I've seen:
> * one per line (as currently)

There's some confusion as to how the one-per-line thing is ordered. I find
it quite obvious, but I've been playing with this for a week now, so it might
just be that I know the answer now. Simply - 

@decA
@decB
@decC
def func():

is equivalent to 

func = decA(decB(decC(func)))

> * commas only

Too much ambiguity in the parsing, I suspect.

> * current list syntax (or some similar variant)

> 4) Indentation
> Proposals also differ on whether or not decorators should introduce a
> new block.  What I've seen:
> * no block
> * block

Guido pointed out that this would lead to the default indentation level 
for a decorated method being 3 tab stops. I also don't like it visually - 
I tried reformatting test_decorators using it, and it looked... strange. 

> I thought the summary above might put some things into perspective so
> that when you're arguing for one syntax or another, you can argue
> separately for the points that matter most to you.  It might be that
> we mostly agree on, say, the need for a keyword, or the block
> indentation (though I'm certainly not holding my breath).  But I'd
> rather hear arguments for the different sections separately because,
> to some degree, they're pretty much orthogonal.

An excellent list! If you don't mind, I might steal this format for the PEP. 
It allows for a lot more alternatives to be covered off in a smaller space
(since many proposals are minor variations on an existing proposal, and
share the same problems).