[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