[IPython-dev] Musings: syntax for high-level expression of parallel (and other) execution control

Edward K. Ream edreamleo@gmail....
Sat Sep 5 16:52:02 CDT 2009

On Fri, Sep 4, 2009 at 3:53 PM, Edward K. Ream <edreamleo@gmail.com> wrote:

> Also, it is in no way an abuse of decorators to use them in unexpected,
> unusual, creative ways, provided only that you are not relying on some
> undocumented accidental feature.

Inspired by this thread, I decided to deepen my understanding of
decorators.  To state my conclusion first, to truly understand decorators it
is a good idea to completely ignore pep 318 and all related tutorials :-)

Indeed, everything you need to know, (everything there *is* to know) about
decorators is in the Reference Guide:

Specifically, the reference guide has only this to say about decorators:


A function definition may be wrapped by one or more
Decorator expressions are evaluated when the function is
defined, in the scope that contains the function definition. The result must
be a callable, which is invoked with the function object as the only
argument. The returned value is bound to the function name instead of the
function object. Multiple decorators are applied in nested fashion. For
example, the following code:

def func(): pass

 is equivalent to:

def func(): pass
func = f1(arg)(f2(func))

Imo, this is a rare example where the most consise explanation is also the
clearest and best.  It is best because it does not deal with the blah blah
blah of expectations.  It implicitly says that one is free to use decorators
in *any* way, subject only to the constraint that the decorator expression
evaluates to a callable.  Failure of the decorator to evaluate to a callable
of *some* kind is the only way to "abuse" a decorator, and the compiler will
not allow such abuse :)  In particular, there is no requirement that the
callable be in *any* way related to func!

The simplicity of decorators renders them neither useless nor
uninteresting.  Unlike tutorials, the reference does not tell how to
implement, say, @trace.  We are left with a sense of possibility.

Edward K. Ream email: edreamleo@gmail.com
Leo: http://webpages.charter.net/edreamleo/front.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/ipython-dev/attachments/20090905/078fba14/attachment.html 

More information about the IPython-dev mailing list