Alternative decorator syntax decision

Avner Ben avner at
Wed Aug 25 19:43:07 CEST 2004

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 

My vote: C2, E4, J2


More information about the Python-list mailing list