[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