elements of decorator syntax suggestions

[Jeff Shannon]

Anthony Baxter wrote:

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

So one way of looking at this, then, is that the @ is (very loosely) 
semantically equivalent to an opening paren, with the closing paren 
being implied?

This makes sense if one thinks of decorators as a wrapper function that 
contains the true function.  It doesn't make quite so much sense when 
one is talking about decorators as meta_data_ which is attached to the 
function.  Clearly, decorators *can* be used in either sense, and 
equally clearly people who want metadata _will_ use decorators for that 
purpose.  But I suspect that at least part of the objection to the 
current syntax is that it doesn't fit with the model that would be 
expected for metadata, for which use-case function attributes seem a 
better fit.  There's a fundamental difference between the decorator 
being a (possibly recursive) container for a function, and functions 
being a container for a set of associated data (which might be other 
callables), and that distinction hasn't been explicitly addressed so far 
as I've seen.  (But note that I've only been reading discussions here, 
and haven't followed up on the py-dev archives.)

(I *still* don't like the two-or-more-lines-per-def, but it does make 
decorators-before-def seem more reasonable.)

Jeff Shannon
Technician/Programmer
Credit International