[Python-Dev] Re: Decorators after 'def' should be reconsidered (original) (raw)

Andrew Durdin adurdin at gmail.com
Thu Aug 12 07:16:32 CEST 2004

On Thu, 12 Aug 2004 01:04:43 +0200, Christophe Cavalaria <chris.cavalaria at free.fr> wrote:

barnesc at engr.orst.edu wrote: > > - For which method is it visually easier to find the function def?

None of them. A good syntax coloring would even make it easier in fact.

One very nice thing with Python to date is that it is very easy to read even without syntax coloring--I think that's a feature worth keeping.

On the second hand, the Option B makes it much harder to find the function code once you've found the function def.

Barely harder at all than the usual function with a docstring -- you just look below the docstring.

> - For which method is the code in the most logical order?

Option A of course. Since the decorator can be seen as a function that takes the defined function as it's first parameter, it's logical to place the decorator before the definition. @staticmethod def f(): pass is a short version of f = staticmethod( def f(): pass )

Except that in actual fact it is a short version of

def f(): pass f = staticmethod(f)

> Note that Option A causes you to skim all the way through > the docstring and the decorators to find out which function > is being defined. At this point, you have to start over > at the docstring, to find out what the function actually does.

This is false of course, any good syntax coloring would give you a good contrast between the function itself and the decorators. That way, it'll be easy to find the first line that isn't colored like a decorator. On the Option B, you'll have to identify 3 blocs of data : the function def, the decorator bloc and the function body.

Relying on syntax coloring is a Bad Thing. :)

More information about the Python-Dev mailing list