@decorator syntax is sugar, but for what exactly?
jeff at ccvcorp.com
Tue Aug 10 02:49:13 CEST 2004
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
>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.
More information about the Python-list