<div dir="ltr"><br><div class="gmail_extra">2016-10-06 13:50 GMT+02:00 Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span>:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The shadow thread idea will hopefully prove successful in addressing<br>
the last major rough spot in the UX, which is the ability to easily<br>
integrate asynchronous components into an otherwise synchronous<br>
application.<br></blockquote><div><br></div><div>That's my opinion as well. If I had to run asyncio coroutines from synchronous code, I'd probably take advantage of the Executor interface defined by concurrent.futures. Executors handle resource management through a context manager interface, which is a good way to start and clean after the shadow thread. Also, the submit method returns a concurrent.futures.Future, i.e. the standard for accessing an asynchronous result from synchronous code. Here's a simple implementation:<br><a href="https://gist.github.com/vxgmichel/d16e66d1107a369877f6ef7e646ac2e5">https://gist.github.com/vxgmichel/d16e66d1107a369877f6ef7e646ac2e5</a><br><br></div><div>If this is not enough, (say one wants to write a synchronous API to an asynchronous library), then it simply is a matter of instantiating the executor once in the module and wrap all the coroutines to expose with executor.submit and Future.result. This might provide an acceptable answer to the DRY thing that has been mentioned a few times, though I'm not convinced it is such a problematic issue (at least nothing that sans-io already addresses in the first place).<br><br></div></div></div></div>