@decorator syntax is sugar, but for what exactly?

[Jeff Shannon]

Dan Sommers wrote:

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

>When I see f( x ), I think that f is a function bound by def (or an
>extremely close relative, such as class or staticmethod), and that I can
>grep for it somewhere, either in the source code or the library
>reference.  I also think, rightly or wrongly, that f *was* bound,
>*before* I needed it, and *does not change over time*.
>
>When I see apply( f, x ), I think that f varies over time, and is some
>sort of a callback or plugin or whatever, and is *not* the name of an
>actual function bound by def.  
>

Um, I think you're missing the point, here.  The apply() has nothing to 
do with whether func() is bound by def or by assignment -- both cases 
given here are intended to allow the easy passing of variable argument 
lists to functions.

In other words, you're thinking of calling a function through a function 
pointer, but what's actually being shown is passing a pointer to a 
parameter struct.  The old style requires a separate function [apply()] 
to be called that dereferences the parameter struct and feeds parameters 
to the called function one-by-one, while the new style dereferences the 
parameter struct in-place.

If you're going to compare this to any real C/C++ construct, it's much 
closer to the issue of (C) pass-by-pointer vs. (C++) pass-by-reference 
syntax, but even that's a really distant stretch.

Jeff Shannon
Technician/Programmer
Credit International