[Python-ideas] async: feedback on EventLoop API

[Jasper St. Pierre]

I read over the wait_one() proposal again, and I still don't understand it,
so it would need more explanation to me.

But I don't see the point of avoiding callbacks. In this case, we have two
or more in-flight requests that can be finished at any time. This does not
have a synchronous code equivalent -- callbacks are pretty much the only
mechanism we can use to be notified when something is done.



On Wed, Dec 19, 2012 at 12:26 PM, Guido van Rossum <guido at python.org> wrote:

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



-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121221/baf5d6ba/attachment.html>