[Python-ideas] async: feedback on EventLoop API

[Guido van Rossum]

On Tue, Dec 18, 2012 at 10:41 PM, Jasper St. Pierre
<jstpierre at mecheye.net> wrote:
> On Wed, Dec 19, 2012 at 1:24 AM, Guido van Rossum <guido at python.org> wrote:
>
> ... snip ...
>
>> That looks reasonable too, although the signature may need to be adjusted.
>> (How does it cancel the remaining tasks if it wants to? Or does par() do
>> that if this callback raises?) maybe call it filter?
>
>
> The subtask completion callback can call abort() on the overall par_task,

Tasks don't have abort(), I suppose you meant cancel().

> which could cancel the rest of the unfinished tasks.
>
>     def abort_task(par_task, subtask):
>         try:
>             return subtask.result()
>         except ValueError:
>             par_task.abort()
>
> The issue with this approach is that since the par() would return values
> again, not tasks, we'd can't handle errors locally. Futures are also
> immutable, so we can't modify the values after they resolve. Maybe we'd have
> something like:
>
>     def fail_silently(par_task, subtask):
>         try:
>             subtask.result()
>         except ValueError as e:
>             return Future.completed(None) # an already completed future that
> has a value of None, sorry, don't remember the exact spelling
>         else:
>             return subtask
>
> which allows us:
>
>     for task in par(*tasks, subtask_completion=fail_silently):
>         # ...
>
> Which allows us both local error handling, as well as batch error handling.
> But it's very verbose from the side of the callback. Hm.

Hm indeed. Unless you can get your thoughts straight I think I'd
rather go with the wait_one() API, which can be used to build anything
else you like, but doesn't require one to be quite so clever with
callbacks. (Did I say I hate callbacks?)

-- 
--Guido van Rossum (python.org/~guido)