Deprecating the 'in process kernel' machinery?

[Thomas Kluyver]

When we first introduced the Qt console, thinking about the kernel/frontend separation mostly as a way to provide multiple frontends for the Python kernel, we wrote some machinery to run a kernel 'in process', without the ZMQ sockets.

Since then, the most popular frontends are Javascript-based, and we've discovered the value of the protocol in supporting kernels for languages other than Python. The in-process kernel machinery has become a poorly-maintained, little-used corner of the code, eliciting a silent groan whenever I see an issue asking about it. It's de-facto deprecated already, and I'd like to make this official, so we can eventually get rid of that code entirely.

There's one major use case I've seen for the IPK machinery: people writing PyQt GUI applications who want to embed the Qt console and use it to interactively manipulate objects in the same process. This is definitely a valid and interesting thing to do, so what can we suggest as an alternative to IPK?

A: Embed the kernel in the application and run the Qt console as a separate window. I think we have examples of this around somewhere, though I forget where.

B: Make the Qt application (with embedded console) manipulate the objects of interest in a separate process, which also runs the kernel machinery. This may have some other advantages to the application, but it's a lot of work and clearly not suitable for every case.

C: Embed both console and kernel in the same application, but still using ZMQ sockets so that they can use more of the standard communication machinery. We have the machinery to integrate the kernel with the Qt event loop, so this should be possible; is anyone aware of any examples of code doing this?

Thanks,

Thomas