Greg Smith & I are looking at this at the core dev sprint, and we think some variant of the "atomic until" idea should work, but there's a prerequisite change to the way "async with" works: the "GET_AWAITABLE" opcodes need to be avoided in this case, as they call __await__, and hence may run arbitrary Python code. We can't see any immediate barriers to moving those calls up into BEFORE_ASYNC_WITH, such that what ends up on the eval loop's stack is the already resolved iterable for use by YIELD FROM, rather than combining GET_AWAITABLE+YIELD_FROM the way a normal await expression does. That would then give the preamble: BEFORE_ASYNC_WITH (resolves __aenter__ and __aexit__ to iterables) LOAD_CONST 0 YIELD_FROM (need to skip signal processing here) SETUP_ASYNC_WITH And the postamble: POP_BLOCK (need to skip signal processing until YIELD_FROM) LOAD_CONST 0 WITH_CLEANUP_START LOAD_CONST 0 YIELD_FROM WITH_CLEANUP_FINISH We also agree that adding some kind of test injection hook (potentially limited to pydebug builds, depending on exactly how it works) is likely to be a necessary to be able to test this.