On Mon, Aug 28, 2017 at 6:22 PM, Greg Ewing
But almost nobody converts the code by simply slapping async/await on top of it
Maybe not, but it will also affect refactoring of code that is *already* using async/await, e.g. taking
async def foobar(): # set decimal context # use the decimal context we just set
and refactoring it as above.
There's no code that already uses async/await and decimal context managers/setters. Any such code is broken right now, because decimal context set in one coroutine affects them all. Your example would work only if foobar() is the only coroutine in your program.
Given that one of the main motivations for yield-from (and subsequently async/await) was so that you *can* perform that kind of refactoring easily, that does indeed seem like a problem to me.
With the current PEP 550 semantics w.r.t. generators you still can refactor them. The following code would work as expected: def nested_gen(): # use some_context def gen(): with some_context(): yield from nested_gen() list(gen()) I saying that the following should not work: def nested_gen(): set_some_context() yield def gen(): # some_context is not set yield from nested_gen() # use some_context ??? list(gen()) IOW, any context set in generators should not leak to the caller, ever. This is the whole point of the PEP. As for async/await, see this: https://mail.python.org/pipermail/python-dev/2017-August/149022.html Yury