@decorator syntax is sugar, but for what exactly?

[Dan Sommers]

On Sun, 8 Aug 2004 18:24:58 +1000,
Anthony Baxter <anthonybaxter at gmail.com> wrote:

> In many cases, these new features actually lead to smaller, simpler
> code. I challenge _anyone_ to tell me that
>   apply(func, args, kwargs) 
> is better than 
>   func(*args, **kwargs)

Okay, I will.  The old way is better than the new way.

Explicit is better than implicit, after all.

Given your second example, is func the name of a function or an object
that references a function?  Can I grep my source code to find a
function named func?  (Okay, I'll find the variable named func, so at
least I'll have some clue as to what's going on.)  Is there a "from
module import func" statement in sight?  What happens when I look up
"func" in the Python documentation to see if it's a built in name?

C did the same thing recently.

Old C:  (*f)( argument );

New C:  f( argument );

With the old syntax, I knew immediately that f was a pointer to a
function and that the function to which it pointed was being called
indirectly.  With the new one, I have to track down a definition or
declaration of f to see that.  Yes, this used to be much more important
than it is now.  Perhaps my years of assembly language applications in
extremely tight situations and are showing through.

Yes, I know that Python functions are first class objects and should be
treated as such.  Yes, I know that Python is not C.  But with function
application being built right into the syntax of the language (i.e., an
identifyer followed by a parenthesized argument list), I would like to
see a visual difference between calling a named function vs. calling a
function indirectly through some sort of reference.  Yes, I also know
that in most cases "it's obvious from context," but with the old way, it
was obvious without any context and evident to the simplest of automated
tools.

That all said, when I use the new syntax (okay, you got me, I do use the
new syntax on occasion), I always leave a comment nearby to explain
what's going on.  I agree:  the *code* is smaller and arguably simpler,
but the *program* and the *software* are not.

Regards,
Dan

-- 
Dan Sommers
<http://www.tombstonezero.net/dan/>
Never play leapfrog with a unicorn.