[Python-ideas] Async API

[Yury Selivanov]

On 2012-10-25, at 11:28 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.

-
Yury