It takes time to get used to it, but eventually you don't have to think about the event loop. There really is no need for any comment of that kind at all. The beauty is that *nothing* blocks the event loop...<br><br>On Wednesday, October 8, 2014, Dan O'Reilly <<a href="mailto:oreilldf@gmail.com">oreilldf@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ah, right. I find the terminology confusing myself, and I probably got it wrong. I meant "non-blocking" as in - "this won't block the event loop", not "this won't block the coroutine". I'll try to clarify that. Thanks!</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 9, 2014 at 12:03 AM, Guido van Rossum <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','guido@python.org');" target="_blank">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This looks neat. I skimmed the README, and I noticed you marked up most "yield from" epressions with "# non blocking". That feels confusing to me, because when I read asyncio code, I think fo "yield from" as blocking (the task, if not the world :-). What do you think?<div><br></div><div>--Guido<div><div><br><br>On Tuesday, October 7, 2014, Dan O'Reilly <<a href="javascript:_e(%7B%7D,'cvml','oreilldf@gmail.com');" target="_blank">oreilldf@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">For what it's worth, I ended up writing a module that takes the "threads on top of regular multiprocessing" approach to integrate the two: <a href="https://github.com/dano/aioprocessing" target="_blank">https://github.com/dano/aioprocessing</a>.<div><br></div><div>Re-implementing multiprocessing to use asyncio internally, while an interesting exercise, would require a very large amount of effort both to implement and maintain alongside the current multiprocessing module. I'm not sure it's really worth it when using threads on top of multiprocessing gives you the same effect without requiring you to basically re-implement large parts of the multiprocessing module.<div><br></div><div>Anyway, we'll see if it ends up getting much use...</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 26, 2014 at 11:48 PM, Ryan Hiebert <span dir="ltr"><<a>ryan@ryanhiebert.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span><br><div><blockquote type="cite"><div>On Jul 26, 2014, at 10:43 PM, Guido van Rossum <<a>guido@python.org</a>> wrote:</div><br><div><div dir="ltr">I'm going to go out on a limb here and say that it feels too early to me. First someone has to actually solve this problem well as a 3rd party package before we can talk about adding it to the asyncio package. It doesn't actually sound like Billiards has adapted to asyncio yet (not that I have any idea what Billiards is -- it sounds like a fork of multiprocessing actually?).</div></div></blockquote><br></div></span><div>Yep, Billiard is a fork of multiprocessing: <a href="https://pypi.python.org/pypi/billiard" target="_blank">https://pypi.python.org/pypi/billiard</a></div></div></blockquote></div><br></div>
</blockquote></div></div></div><span><font color="#888888"><br><br>-- <br>--Guido van Rossum (on iPad)<br>
</font></span></blockquote></div><br></div>
</blockquote><br><br>-- <br>--Guido van Rossum (on iPad)<br>