[Python-Dev] Re: Decorators after 'def' should be reconsidered

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