[Python-ideas] async: feedback on EventLoop API

[Jasper St. Pierre]

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,
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.


> But what did you think of my wait_one() proposal? It may work beter in a
> coroutine, where callbacks are considered a nuisance.
>

To be honest, I didn't quite understand it. I'd have to go back and re-read
PEP 3148.


> I like the initial approach, but the details need fleshing out. I think it
>> would be neat if we could have several standard behaviors in the stdlib:
>> subtask_completed=fail_silently, subtask_completed=abort_task, etc.
>>
>> > And, of course, we should make sure that we can handle the four
>>> situations
>>> > mentioned in [0] , even if we don't solve them with callbacks.
>>> >
>>> > [0] https://gist.github.com/3889970
>>>
>>> That's longwinded and written in a confrontational style. Can you
>>> summarize?
>>>
>>
>> Yeah, this was more at a lament at libraries like jQuery that implement
>> the CommonJS Promise/A specification wrong. It's really only relevant if we
>> choose to add errbacks, as it's about the composition and sematics between
>> callbacks/errbacks, and chaining the two.
>>
>
> No, no, no! Please. No errbacks. No chaining. Coroutines have a different
> way to spell those already: errbacks -> except clauses, chaining ->
> multiple yield-froms in one coroutine, or call another coroutine. Please.
>
> --Guido
>
>
> --
> --Guido van Rossum (on iPad)
>



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