Alternative decorator syntax decision

[Colin J. Williams]

Apologies! One response was more than enough.

Colin J. Williams wrote:
> 
> 
> Avner Ben wrote:
> 
>> I believe putting the decorator list before the function header is 
>> generally a bad design decision. While it may make parsing-related 
>> sense, it violates Python's greatest asset: being executable 
>> pseudocode. The way I see it, the latter quality means being able to 
>> look at the code and see clearly and immediately what requirements 
>> from the real world the code was written the serve. Functions and 
>> methods are major code entities that are naturally expected to 
>> represent discrete functional requirements from the code, to this or 
>> that level of detail. I expect to learn from the method name, the 
>> class it is in and the list of arguments it takes, everything I need 
>> to know about the functional requirement it implements. If that is not 
>> enough, I will look at the docstring, if present. Everything else the 
>> method has to offer is conveniently hidden below. Decorators of the 
>> type discussed recently - with the exception of staticmethod and 
>> classmethod - are technical detail of the kind I would like to see 
>> hidden below. Putting them on top, prior to the what the method does 
>> (its name etc.) compromises the design quality of the code, reducing 
>> it to yet another abbreviation-based, self-centered technical 
>> scripting language.
>> The one esception I saw was J2, which, although putting the decorators 
>> before the proper method header, uses indentation to state "this is an 
>> extra piece of technicality which you are free to ignore - the def is 
>> below."
>>
>> My vote: C2, E4, J2
>>
>>     Avner.
> 
> Your expectation list makes sense to me.  There is merit in having the 
> docstring before the 'decorator', i.e. E4
> 
> Colin W.
>