[Python-ideas] Async API

[Steve Dower]

This could alse be another application for extension options on futures:

try:
    ...
finally:
    yield do_cleanup_1().set_options(never_raise=True)
    yield do_cleanup_2().set_options(never_raise=True)

The scheduler can then ignore exceptions (including CancelledError) instead of raising them. ('set_scheduler_hint' may be a better name than 'set_options', now I come to think of it. I like the extensibility of this, since I don't think anyone can predict what advanced options every scheduler may want - the function takes **params and updates a (lazily created) dict on the future.)

Of course, this will also work (and is pretty much equivalent):

try:
    ...
finally:
    try: yield do_cleanup_1()
    except: pass
    try: yield do_cleanup_2()
    except: pass

We'll probably need/want some form of 'atomic' primitive anyway, which might work like this:

yield atomically(do_cleanup_1, do_cleanup_2, ...)

Though the behaviour of this when exceptions are involved gets complicated - do we abort all of them? Pass the exception on? Continue anyway? Which exception gets reported?


Cheers,
Steve

________________________________________
From: Python-ideas [python-ideas-bounces+steve.dower=microsoft.com at python.org] on behalf of Guido van Rossum [guido at python.org]
Sent: Wednesday, October 24, 2012 7:51 PM
To: Yury Selivanov
Cc: python-ideas at python.org
Subject: Re: [Python-ideas] Async API

On Wed, Oct 24, 2012 at 7:28 PM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> On 2012-10-24, at 9:34 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> [...]
>> (Note that in the face of preemption, I don't think it's possible
>> to solve this problem completely without language support, because
>> there will always be a small window of opportunity between
>> entering the finally clause and getting into the with-statement
>> or whatever that you're using to block asynchronous signals.)
>
> Agree.
>
> In my experience, though, broken finally blocks due to interruption
> by a signal is a very rare thing (again, that maybe different for
> someone else.)

We're far from our starting point: in a the yield-from (or yield)
world, there are no truly async interrupts, but anything that yields
may be interrupted, if we decide to implement timeouts by throwing an
exception into the generator (which seems the logical thing to do).
The with-statement can deal with this fine (there's no yield between
entering the finally and entering the with-block) but making the
cleanup into its own task (like Steve proposed) sounds fine too.

In any case this sounds like something that each framework should
decide for itself.

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-ideas mailing list
Python-ideas at python.org
http://mail.python.org/mailman/listinfo/python-ideas