<div dir="ltr">Just don't oversell run_until_complete() -- some people coming from slightly different event loop paradigms expect to be able to pump for events at any point, possibly causing recursive invocations. That doesn't work here (and it's a feature it doesn't).<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 8, 2016 at 8:23 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On 9 August 2016 at 08:37, Sven R. Kunze <span dir="ltr"><<a href="mailto:srkunze@mail.de" target="_blank">srkunze@mail.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>From what I've heard in the wild, that most if not all pieces of async are mirroring existing Python features. So, building async basically builds a parallel structure in Python resembling Python. Async generators complete the picture. Some people (including me) are concerned by this because they feel that having two "almost the same pieces" is not necessarily a good thing to have. And not necessarily bad but it feels like duplicating code all over the place especially as existing functions are incompatible with async.<br></blockquote><div><br></div></span><div>It's a known problem that applies to programming language design in general rather than being Python specific: <a href="http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/" target="_blank">http://journal.stuffwithstuff.<wbr>com/2015/02/01/what-color-is-<wbr>your-function/</a><br></div><div><br></div><div>The async/await model used in C# and Python 3.5+ aims to at least make it clear whether you're dealing with "red" (asynchronous) or "blue" (synchronous) code, but some use cases will still benefit from using something like gevent to bridge between the synchronous world and the asynchronous one: <a href="http://python-notes.curiousefficiency.org/en/latest/pep_ideas/async_programming.html#gevent-and-pep-3156" target="_blank">http://python-notes.<wbr>curiousefficiency.org/en/<wbr>latest/pep_ideas/async_<wbr>programming.html#gevent-and-<wbr>pep-3156</a><br><br></div><div>In cases where blocking for IO is acceptable, the "run_until_complete()" method on event loop implementations can be used in order to invoke asynchronous code synchronously: <a href="http://www.curiousefficiency.org/posts/2015/07/asyncio-background-calls.html" target="_blank">http://www.curiousefficiency.<wbr>org/posts/2015/07/asyncio-<wbr>background-calls.html</a><br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As I understand it, one goal is to be as close to sync code as possible to make async code easier to understand. So, if dropping 'await's all over the place is the main difference between current async and sync code, I get the feeling both styles could be very much unified. (The examples of the PEP try to do it like this but it wouldn't work as we already discussed.) Maybe, it's too early for a discussion about this but I wanted to dump this thought somewhere. :)<br></blockquote><div><br></div></span></div>One of the big mindset shifts it encourages is to design as many support libraries as possible as computational pipelines and message-drive state machines, rather than coupling them directly to IO operations (which is the way many of them work today). Brett Cannon started the Sans IO information project to discuss this concept at <a href="http://sans-io.readthedocs.io/" target="_blank">http://sans-io.readthedocs.io/</a><br><br></div><span class=""><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div data-smartmail="gmail_signature">Nick Coghlan | <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a> | Brisbane, Australia</div>
</div></span></div>
<br>______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>