[Python-Dev] Re: decorators and 2.4

[Brian L.]

As I see it, any decorator that appears on lines previous to a
function impairs code readability by making the function harder to
find. When editing code with the standard 4-space tab, the function
name is very conveniently lined up with the code below it, and in most
code I've seen, there's a blank line above it, like this:

def something(foo): 
    do_something()

def somethingelse(bar):
    do_something_else()

Now say we were to add decorators to this. Then visually, to find the
function, you'd be searching through a non-predetermined set of
decorators first, as opposed to searching for a solid piece of
whitespace then scrolling your eyes one line down, a fixed position
from the left edge of the editor. The function name would be embedded
in noise, making the code more confusing to edit.

This particular issue can be remedied in two ways. First off, a list
of decorators with brackets, as Phillip's solution makes possible, but
with some limitation to prevent multiple lines of them (or at least a
prescribed coding convention prohibiting it without true enforcement).
It would still take away from readability a little bit, but not in
such a bad way. The brackets actually set off the decorators nicely.
Something like:

[decorators]
def func(args):
    pass

The other solution I see is something like what Bill said which is:

def func (args) as [decorators]:

The idea of bracketing them as a list is, I think, a very good one,
and it would of course still have to be determined whether decorators
are functions, whether they should be called, etc. I kind of like the
idea of them being functions that are called on the function, and if
they need additional arguments, make them higher order functions such
that the decorator list element is called with func as its argument.

Just my 2c,

Brian


On Fri, 25 Jun 2004 16:18:38 -0400, Fred L. Drake, Jr. <fdrake at acm.org> wrote:
> 
> On Friday 25 June 2004 04:09 pm, Phillip J. Eby wrote:
>  > * Whether to have a 'decorate' function at all, or whether it's better to
>  > just list specialized decorator objects/functions (I generally favor the
>  > latter, since 'decorate' is IMO a dead chicken that hasn't appeared in any
>  > widely-supported syntax proposals to date).
> 
> Ooohh... time for some fun!  Some proposals have included "as".  Since "as"
> isn't really a keyword, how about:
> 
>     from decorate import decorate as as
> 
>     as(classmethod)
>     def myAlternateConstructor(...):
>         # make something interesting:
>         return 42
> 
> Too bad this is ugly for the simple attribute decorator:
> 
>     as(spam="fidget")
>     def foo(...):
>         send_fred_more_spam_please()
> 
>   -Fred
> 
> --
> Fred L. Drake, Jr.  <fdrake at acm.org>
> PythonLabs at Zope Corporation
> 
> 
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/zorander%40gmail.com
> 


-- 
The years ahead pick up their dark bags.
They move closer. There's a slight rise in the silence

then nothing.