A decorator syntax not yet mentioned (I think!)

[Mark Bottjer]

Peter Hansen wrote:
> Mark Bottjer wrote:
>> 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.

Except that the action happens magically after the def, even though the 
decorator is before it. To me, this has the appearance of changing the 
action of def. I'm trying to argue based on how it appears, rather than 
how we know it to be implemented.

>> 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 concede that this would seem to set precedent (in fact, most control 
statements have something like this). But in all those cases, all the 
blocks contain normal code, right? This would be the only one in which 
one of the blocks contained purely "declarative" statements. If the 
decorators were coded as function calls instead of function names, then 
I'd say it has parity with if/else, but they aren't.

In any case, it seems that we might need to "agree to disagree" on this 
point. :)

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

That *is* pretty odd.

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

FWIW, I don't object to the keyword, I object to the indented block. I 
agree that newbies will need to look either up. My only real concern is 
that certain suggested syntaxes (mostly the list or tuple forms) look 
innocuous enough that newbies may not realize that they've hit something 
new. Everything past there seems more and more like simple preference.

   -- Mark