[Python-ideas] async: feedback on EventLoop API
Guido van Rossum
guido at python.org
Wed Dec 19 18:26:33 CET 2012
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)
More information about the Python-ideas
mailing list