[Python-ideas] Async API

[Yury Selivanov]

On 2012-10-25, at 11:43 AM, Steve Dower <Steve.Dower at microsoft.com> wrote:

>>>>>> Mine is a quick hack to add 'gi_in_finally' property to generators 
>>>>>> and see how good/bad it is.
>>>>> 
>>>>> I feel it's a code smell if you need to use this feature a lot. If 
>>>>> you need it rarely, well, use one of the existing work-arounds.
>>>> But the feature isn't going to be used by users directly.  It will be 
>>>> used only in scheduler implementations.  Users will just write 
>>>> 'finally' blocks and they will work as expected. This just makes 
>>>> coroutines look and behave more like ordinary functions.  Isn't it 
>>>> one of our goals--to make it convenient and reliable?
>>> 
>>> I'm agree with the intent, but I'm more worried about the broadness of this approach. What happens in this case?
>>> 
>>> try:
>>>   try:
>>>       yield some_op()
>>>   finally:
>>>       yield cleanup_that_raises_network_error()
>>> except NetworkError:
>>>   # will we ever see this?
>>> 
>>> Basically, I don't think we can handle the "don't raise" cases entirely automatically, though I'd like to be able to.
>> 
>> We can.  You can experiment with the approach--I've implemented it a bit differently and it proved to work.  Now we're just talking about making this feature supported on the interpreter level.
>> 
>> As for your example - I'm not sure what's the NetworkError is and how it relates to TimeoutError...
>> 
>> But if you have something like this:
>> 
>> try:
>>     try:
>>         yield some_op().with_timeout(0.1)
>>     finally:
>>         yield something_else()
>> except TimeoutError:
>>     # Then everything would be just fine here.
>> 
>> Look, it all the same as if you just drop yields.  Generators already support 'finally' clause perfectly.
> 
> The type of the error is irrelevant - if something_else() might raise an exception that is expected, it won't be passed in because the scheduler is suppressing exceptions inside finally blocks. Or perhaps I've misunderstood the point of gi_in_finally?

The only thing scheduler will ever suppress--is its *own* intent to
*interrupt* something (until `gi_in_finally` gets back to 0.)
Every other exception must be propagated as usual, without even
checking `gi_in_finally` flag.

-
Yury