[Async-sig] Inadvertent layering of synchronous code as frameworks adopt asyncio

[Glyph]

> As for jupyter, I think the best thing for them to do is run all notebook user code in a separate thread dedicated to that purpose, and hide the fact that the notebook itself is running asyncio as much as possible. That user thread can start up its own event loop if it wants, but that's not the jupyter kernel's concern. Until it can be refactored to use separate threads, I think it would be reasonable to let it start up new event loops (and run them for finite durations), although asyncio currently disallows that as long as you're on the same thread as an outer event loop. 


Definitely disagree about this! If you start hiding this, then it’s impossible to start background tasks which run on the event loop and update a cell; not to mention that depending on your library (ie whether it’s something the kernel itself wants to import), then makes the thread that defined *some* of your classes at import time start being different from the thread that’s executing your code.

I frequently use tornado.platform.twisted to do async background work in notebooks and it would break a ton of my work to start requiring manual event-loop management that can’t persist between cells.

It’s fine for the kernel to just block for a while if it has synchronous work to do; that’s one of the core benefits of separating the kernels from the UI.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20190325/b298c947/attachment.html>