[Python-ideas] Async API

Yury Selivanov yselivanov.ml at gmail.com
Thu Oct 25 08:18:51 CEST 2012


On 2012-10-25, at 12:37 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:

> On 2012-10-24, at 10:51 PM, Guido van Rossum <guido at python.org> wrote:
> 
>> 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.
> 
> BTW, is there a way of adding a read-only property to generator objects - 
> 'in_finally'?  Will it actually slow down things?

Well, I couldn't resist and just implemented a *proof of concept* myself.
The patch is here: https://dl.dropbox.com/u/21052/gen_in_finally.patch

The patch adds 'gi_in_finally' read-only property to generator objects.

There is no observable difference between patched & unpatched python
(latest master) in pybench.

Some small demo:

>>> def spam():
...     try:
...         yield 1
...     finally:
...         yield 2
...     yield 3
>>> gen = spam()
>>> gen.gi_in_finally, gen.send(None), gen.gi_in_finally
(0, 1, 0)
>>> gen.gi_in_finally, gen.send(None), gen.gi_in_finally
(0, 2, 1)
>>> gen.gi_in_finally, gen.send(None), gen.gi_in_finally
(1, 3, 0)
>>> gen.gi_in_finally, gen.send(None), gen.gi_in_finally
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration

If we decide to merge this in cpython, then this whole problem with
'finally' statements can be solved (at least for generator-based
coroutines.)

What do you think?

-
Yury


More information about the Python-ideas mailing list