> 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.
_______________________________________________
Async-sig mailing list
Async-sig@python.org
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/