A decorator syntax not yet mentioned (I think!)

[Mark Bottjer]

Michael Sparks wrote:
> Looking at the wiki it states (as negative points):
>    1 New keyword
>    2 Overkill for the simple case like classmethod
>    3 Many people felt it was wrong use of an identation suite.
>    4 Has the same problem as 5.A, in that the decorate block implicitly
>      affects the following def. This does not occur elsewhere in Python.
>    5 Technical problems with the current grammar parser if a suite
>      *starts* with an optional part. (Ending with an optional part, such
>      as "else:" is OK, but starting with one is not.) 
>    6 No implementation currently exists. 
[snip]
> Item 3 is opinion, but I don't know where the arguments are leading to
> that point, so I'll just take that at face value.

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.

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

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.

> Regarding 4, it strikes me that this isn't the case (unless it strictly
> means "block"!).

It meant strictly "block". :)

 > An import at the beginning of a block changes the
> meaning of [the rest of] a block.

Yes, by means of changing the program state--specifically, the namespace 
used to resolve identifiers. The decorate block changes the meaning of 
only the *next* statement by means of changing the parser (not program) 
state. I see them as quite different. YMMV.

 > Similarly a class statement changes the meaning of
> the defs immediately following it.

It affects the meaning of the defs indented under it. The only way it 
affects anything after it is by the modifications it makes to the 
namespace. Again, the statements at the same indentation level are 
coupled only via namespace, not parser state. The statements in indented 
suites are coupled via parser state, but that coupling is made obvious 
via the indentation.

> I'd agree that it's not ideal, but
> the argument that code preceding the def isn't allowed because it
> changes the meaning of the def doesn't make sense to me - that's what
> the @ syntax does.

Indeed, and that partially why I like the '@' symbol (or possibly a meta 
keyword). If we're going to add something which completely disregards 
the existing indentation/coupling idioms, then it should have an obvious 
visual trigger.

   -- Mark