Alternative decorator syntax decision
Colin J. Williams
cjw at sympatico.ca
Wed Aug 25 22:00:15 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