xeus enables custom kernel authors to implement Jupyter kernels more easily. It takes the burden of implementing the Jupyter Kernel protocol so developers can focus on implementing the interpreter part of the Kernel.



In the following documentation:

  • interpreter refers to the part of the kernel responsible for executing the code, completing the code etc.

  • client refers to the Jupyter client, which can be Jupyter Notebook/JupyterLab/Jupyter console etc.

  • user refers to people using the kernel on any Jupyter client.

The easiest way to get started with a new kernel is to create a class inheriting from the base interpreter class xeus::xinterpreter and implement the private virtual methods

  • execute_request_impl: See execute_request Code execution request from the client.

  • complete_request_impl: See complete_request Code completion request from the client.

  • inspect_request_impl: See inspect_request Code inspection request (using a question mark on a type for example).

  • is_complete_request_impl: See is_complete_request Called before code execution (terminal mode) in order to check if the code is complete and can be executed as it is (e.g. when typing a for loop on multiple lines in Python, code will be considered complete when the for loop has been closed).

  • kernel_info_request_impl: See kernel_info_request Information request about the kernel: language name (for code highlighting), language version, terminal banner etc.

  • shutdown_request_impl: Shutdown request from the client, this allows you to do some extra work before the kernel is shut down (e.g. free allocated memory).

A dummy kernel is provided as an example. You can also find real kernel implementations based on xeus: