A decorator syntax not yet mentioned (I think!)

[Peter Hansen]

Mark Bottjer wrote:
> The contention was that indentation is used to indicate the effective 
> scope in other contexts: e.g., def changes how the statements *indented 
> under it* are handled (they are packed into a code object instead of 
> executed immediately), but doesn't change how the next statement at the 
> same indentation level is handled (the statement result may change, due 
> to coupling via common data, but the statement itself is handled exactly 
> as it would be were the previous statement not present). 

 > With this
> syntax, though, the decorate block changes how the def statement is 
> handled, even though they are at the same indentation level.

Changes it how?  The definition of this whole decorator idea has been
that it is equivalent to applying the decorator functions *after* the
def has completed, as in "func = decorator(func)".  This does not
in any way changed how the def statement itself is handled.

> Put another way: applying what I know about how indentation is used 
> elsewhere in Python to this syntax, I would expect the effect of the 
> decorate statement to be limited to the statements indented under it. I 
> would not expect it to affect the next statement at the same level 
> except by the normal coupling of namespace (program state).

You don't think of "if" and "else" as being related?  When the
expression that is evaluated in the if is true, the "else"
is skipped over...  I know: that's just program state as you said.
But so is the effect of the decorator, whether it's spelled "@"
or "decorate:"...

Anyway, whatever works for @pie syntax should work for decorate:
syntax, I would think.  @pie is even less like the rest of Python
(especially now with this weird "swallow newlines" hack to work
around the possibility that people might try to put multiple
@decorators on the same line).

> Of course, this argument also applies to the prefix @ syntax, but at 
> least with that we have a funny character cluing us in to the special 
> behavior.

While here we have a nice explicit keyword "decorate:" which one
can easily find with a search in the documentation, as opposed to
trying to look up a symbol "@".  I don't buy the argument that a
funny symbol is somehow going to help people who don't already know
what decorators are, any more than an explicit "decorate:" line
would.  Either one says "this is different, go look up what it
means" to a newcomer.

-Peter