Home Original page

Alternative decorator syntax decision

Colin J. Williams cjw at sympatico.ca
Wed Aug 25 22:01:25 EDT 2004 
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.
More information about the Python-list mailing list