<div dir="ltr">I totally agree that async/await should not be tied to any underlying message pump/event loop.  Ensuring that async/await works with existing systems like Tornado is great.<div><br></div><div>As for the two options, option 1 is the expected behavior from developers coming from other languages implementing async/await which is why I found the existing behavior to be so unintuitive.  To Barry and Kevin's point, this problem is exacerbated by a lack of documentation and examples that one can follow to learn about the Pythonic approach to async/await.</div><div><br></div><div>Thanks,</div><div>Roy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 15, 2015 at 7:33 PM, Yury Selivanov <span dir="ltr"><<a href="mailto:yselivanov.ml@gmail.com" target="_blank">yselivanov.ml@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Roy,<br>
<br>
On 2015-12-15 8:29 PM, Roy Williams wrote:<br>
[..]<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
My proposal would be to automatically wrap the return value from an `async` function or any object implementing `__await__` in a future with `asyncio.ensure_future()`.  This would allow async/await code to behave in a similar manner to other languages implementing async/await and would remain compatible with existing code using asyncio.<br>
<br>
What's your thoughts?<br>
</blockquote>
<br></span>
Other languages, such as JavaScript, have a notion of event loop integrated on a very deep level.  In Python, there is no centralized event loop, and asyncio is just one way of implementing one.<br>
<br>
In asyncio, Future objects are designed to inter-operate with an event loop (that's also true for JS Promises), which means that in order to automatically wrap Python coroutines in Futures, we'd have to define the event loop deep in Python core.  Otherwise it's impossible to implement 'Future.add_done_callback', since there would be nothing that calls the callbacks on completion.<br>
<br>
To avoid adding a built-in event loop, PEP 492 introduced coroutines as an abstract language concept.  David Beazley, for instance, doesn't like Futures, and his new framework 'curio' does not have them at all.<br>
<br>
I highly doubt that we want to add a generalized event loop in Python core, define a generalized Future interface, and make coroutines return it.  It's simply too much work with no clear wins.<br>
<br>
Now, your initial email highlights another problem:<br>
<br>
   coro = coroutine()<br>
   print(await coro)  # will print the result of coroutine<br>
   await coro  # prints None<br>
<br>
This is a bug that needs to be fixed.  We have two options:<br>
<br>
1. Cache the result when the coroutine object is awaited first time. Return the cached result when the coroutine object is awaited again.<br>
<br>
2. Raise an error if the coroutine object is awaited more than once.<br>
<br>
The (1) option would solve your problem.  But it also introduces new complexity: the GC of result will be delayed; more importantly, some users will wonder if we cache the result or run the coroutine again.  It's just not obvious.<br>
<br>
The (2) option is Pythonic and simple to understand/debug, IMHO.  In this case, the best way for you to solve your initial problem, would be to have a decorator around your tasks.  The decorator should wrap coroutines with Futures (with asyncio.ensure_future) and everything will work as you expect.<br>
<br>
Thanks,<span class=""><br>
Yury<br>
<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br></span>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/rwilliams%40lyft.com" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/rwilliams%40lyft.com</a><br>
</blockquote></div><br></div>