Decorators proposal

[Brian van den Broek]

Jeff Shannon said unto the world upon 2004-08-10 14:52:

> Christopher T King wrote:
> 
>>> RebelGeekz wrote:
>>>   
>>>
>>>> Just my humble opinion:
>>>>
>>>> def bar(low,high):
>>>>    meta:
>>>>        accepts(int,int)
>>>>        returns(float)
>>>>    #more code
>>>>     
>>
>>
>> Ooh, perty!  I especially like the extension of this idea into function
>> attributes; it looks even cleaner than the .attribute syntax I like.
>>
>> The only problem I see with this is that Guido seems to want 
>> decorators to
>> be more prominent than the function signature itself, so he probably
>> certainly won't go for "hiding" then in a doubly-nested block. 
> 
> 
> More to the point, GvR seems to have decided that decorators, as 
> something that *wraps* a function, belong *outside* the function def 
> rather than inside it.  Being inside the def implies that it's internal 
> to the function, which decorators are not.
> 
> I can see the logic in that, but I really dislike the contorted prefix 
> syntax that's necessary to support the alternative.
> 
> Jeff Shannon
> Technician/Programmer
> Credit International

Hi all,

I'm far too new to programming and Python for my opinion to have even 
feather-weight. I'd been wondering about something similar to the above 
the last few days, but hadn't posted as I didn't feel informed enough 
about the issues. Now that this sort of solution is under some discussion, 
though, I cannot resist.

 From reading much of the @-explosion in the python-dev list it seemed to 
me that Guido's main objection to any syntax that put the decorators after 
the def was that it made it look like the decorators were part of the 
executing function, rather than run only when the def is first run. 
(Similar reasoning seemed behind the expression of regret that docstrings 
aren't above defs.)

Both for decorators and docstrings, putting them above seems odd to 
me--documenting and modifying what exactly? Oh, something lower down :-| 
This way seems to separate them from the function's executable code, yet 
put them where my brain seems to expect them. And, the extra indent makes 
them fairly prominent to my eye.

The other objection I've seen a lot to the general sort of thing proposed 
above would be that it takes a new keyword (though I've read Guido 
relaxing the "no new keyword for decorators" restriction). Could that be 
met either by using a bare ':' or by having ':meta'? (Maybe I am wrong, 
but :name isn't legal outside of slicing is it? And certainly not as the 
start of a line? Thus, wouldn't this eliminate any conflict between this 
use of 'meta' and any possible use of 'meta' as a variable?)

Anyway, conceptually and aesthetically this sort of proposal seems the 
best I've read about. Here's hoping someone with more credibility, 
knowledge, and a better sense of pythonic politics [not meant with any 
snide tone] decides to champion it.

Best to all,

Brian vdB