<p dir="ltr"><br>
On 26 Jun 2015 05:15, "Andrew Svetlov" <<a href="mailto:andrew.svetlov@gmail.com">andrew.svetlov@gmail.com</a>> wrote:<br>
><br>
> > Another issue that bothers me, is code reuse. Independent from whether the<br>
> > 'async def' makes sense or not, it would not allow us to reuse asyncio<br>
> > functions as if they were normal functions and vice versa (if I understood<br>
> > that correctly). So, we would have to implement things twice for the asyncio<br>
> > world and the classic world. To me, it would be important to use one<br>
> > function in either world where it suits me better. I am uncertain if that<br>
> > makes sense but right now it does to me.<br>
><br>
><br>
> Yes, you cannot call async function from synchronous code. There are<br>
> two worlds: classic and async.</p>
<p dir="ltr">Exactly, the sync/async split is inherent in the problem domain. Nobody really likes this consequence of explicitly asynchronous programming models, and this is a good article on why it's annoying: <a href="http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/">http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/</a></p>
<p dir="ltr">However, it's also one of those cases like binary floating point: there are good underlying reasons things are the way they are, but truly coming to grips with them can take a long time, so in the meantime time it's necessary to just accept it as "just one of those things" (like learning negative or complex numbers for the first time). For explicitly asynchronous programming, Glyph's post at <a href="https://glyph.twistedmatrix.com/2014/02/unyielding.html">https://glyph.twistedmatrix.com/2014/02/unyielding.html</a> is a decent starting point on that journey.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>