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

[Fernando Perez]

On Fri, Sep 4, 2009 at 1:18 PM, Darren Dale <dsdale24 at gmail.com> wrote:

> Ok, I didn't appreciate that you defined func where you did in order
> to get access to those local variables. And while I prefer the
> decorator syntax, it is still identical to "def block(): ...;
> profiled(block)", right?

Yes, absolutely.  This is an unconventional, but 100% 'compliant' use
of @ syntax.

> Ok, or:
>
>   def block():
>       for i in range(count):
>           results[i] = do_work(data, i)
>   profiled(block)

Certainly, it's still the normal python equivalence:

@foo
def bar(): pass

==

def bar(): pass
bar = foo(bar)

> One other potential problem that just occurred to me: it is a
> non-standard use of the decorator syntax. When I first saw it I
> thought "wait, where does he call loop?" It happened inside the
> decorator, but the standard use is to rebind the returned value to
> loop (or block, or whatever). PEP318 doesn't mention this pattern you
> have implemented, and I didn't see it at
> http://wiki.python.org/moin/PythonDecoratorLibrary either (I did not
> do an exhaustive search). In this case, since the decorator syntax has
> a very well established purpose, I think the "profiled(block)"
> alternative is much more obvious.

As I mentioned before, it's a non-standard use of @, but I can't claim
to have invented: the Apple GCD and ^{} block discussion forced me to
rethink the problem, and I remembered having seen this pattern in
Sage's @interact implementation.  But it is indeed an unusual and
somewhat surprising use of @decorators, I do admit that.  However, I
actually find it quite clear and I like how it reads inline
immediately.  If this pattern of "inline decorators" becomes popular
for certain uses, the surprise factor will fade.

The reason why I like it as-is, is that it immediately declares the
actions that will affect the block below, much like 'with' declares
the context manager up-front (it's no surprise, since I arrived at
this while thinking about 'with'-based implementations of this idea).

But you are certainly welcome to use the post-block implementation if
you find it clearer, after all the resulting execution is 100% the
same.  I suppose time and usage will tell us which patterns ends up
working better for long-term practice.

Cheers,

f