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
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 interpreter.
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?
Eric.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)