Alternative decorator syntax decision
Avner Ben
avner at skilldesign.com
Wed Aug 25 13:43:07 EDT 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
below."
My vote: C2, E4, J2
Avner.
More information about the Python-list
mailing list