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

[Christophe Cavalaria]

barnesc at engr.orst.edu wrote:

> -----------------------------------------------
> Option A
> -----------------------------------------------
> 
> """
> Hi,
> 
> Performs a binary operation.
> 
> Docstring.
> """
> @staticmethod
> @synchronized(lockvar)
> def f(a, b):
>     return a + b
> 
> """
> Now,
> 
> Performs a simple operation.
> """
> @classmethod
> def g(a):
>     return a
> 
> -----------------------------------------------
> Option B
> -----------------------------------------------
> 
> def f(a, b):
>     @staticmethod
>     @synchronized(lockvar)
>     """
>     Hi,
> 
>     Performs a binary operation.
> 
>     Docstring.
>     """
>     return a + b
> 
> def g(a):
>     @classmethod
>     """
>     Now,
> 
>     Performs a simple operation.
>     """
>     return a
> 
> 
> Now, forget everything you've learned about Python.
> Forget that @ symbols are ugly.
> 
>  - 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. On
the second hand, the Option B makes it much harder to find the function
code once you've found the function def.

>  - 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
)

after all

> 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.

> Option A is especially painful when a large number of functions
> are thrown into a module.  It is almost impossible to grep
> efficiently for the function names.  Thus the code appears
> disorganized, and messy.

I don't understand how grep can be "confused" by the decorators before the
def. Are we talking about the same program ???