[Python-ideas] Async API

[Steve Dower]

>>>>> 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?

Cheers,
Steve