No, we can't, because the async/await are interpreted by the *compiler*, while the presence of an event loop is a condition of the *runtime*.

On Tue, May 5, 2015 at 2:03 PM, Eric V. Smith <> wrote:
On 5/5/2015 2:48 PM, Guido van Rossum wrote:
> Quick notes:
> - I don't think it's really possible to write realistic async code
> independently from an async framework.
> - For synchronous code that wants to use some async code, the pattern is
> simple:
>     asyncio.get_event_loop().run_until_complete(some_async_call(args, etc))
> - We can probably wrap this in a convenience helper function so you can
> just write:
>     asyncio.sync_wait(some_async_call(args, etc))
> - Note that this will fail (and rightly so!) if called when the event
> loop is already running.

If we're going through all of the effort to elevate await and async def
to syntax, then can't the interpreter also be aware if it's running an
event loop? Then, if we are running an event loop, await becomes "yield
from", using the event loop. But if we're not running an event loop,
then await becomes a blocking wait, using some version of
run_until_complete, whether really from asyncio or baked into the

This way, I can write my library code as being async, but it's still
usable from non-async code (although it would need to be called with
await, of course).

I'll admit I haven't thought this all the way through, and I'm still
reading through PEP 492. But if I can write my async code as if it were
blocking using await, why can't it really be blocking, too?


Python-ideas mailing list
Code of Conduct:

--Guido van Rossum (