Jupyter客户端：与内核交互的Python API

需积分: 15 130 浏览量更新于2024-07-18 收藏 399KB PDF 举报

"jupyter-client是用于启动、管理和与Jupyter内核通信的Python API包。" Jupyter客户端库是Jupyter生态系统中的一个关键组件，它提供了与Jupyter内核交互的接口。这个库使得用户能够编写Python代码来控制运行在后台的Jupyter内核，执行代码、接收返回结果，以及管理内核的状态。 1. 消息系统：Jupyter的基础是其消息传递协议，它定义了客户端（如Jupyter Notebook或Lab）与内核之间的通信方式。协议有版本控制，确保不同版本的客户端和内核可以兼容。消息格式包括头部（header）、内容（content）、签名（signature）和元数据（metadata），保证了数据传输的结构化和安全性。 2. Shell通道：shell通道使用ROUTER/DEALER套接字，用于发送执行命令（如执行代码、获取变量信息）和接收执行结果。这些消息通常包含代码单元格的执行请求和响应。 3. IOPub通道：IOPub通道基于PUB/SUB模型，用于广播内核的输出，例如标准输出、错误信息、进度更新和富文本输出。任何订阅此通道的客户端都能接收到这些消息。 4. Stdin通道：当内核需要从用户那里接收输入时，会通过ROUTER/DEALER套接字的stdin通道请求输入。客户端可以通过这个通道提供用户输入，使内核继续执行。 5. 心跳（Heartbeat）：为了检测内核是否仍然活跃，客户端和内核之间会有心跳消息的交换。如果一段时间内没有心跳，客户端可以假设内核已关闭并采取相应措施。 6. 自定义消息：除了预定义的消息类型，开发者还可以创建自定义消息，扩展Jupyter的通信能力。 7. 制作Jupyter内核：创建自定义内核涉及生成连接文件，处理来自客户端的消息，定义内核规范（kernelspec），以便Jupyter知道如何启动特定语言的内核。 8. 简单Python包装器内核：为了创建一个新的内核，至少需要实现几个核心步骤，如处理消息、定义内核信息等。Jupyter_client提供了示例和指导，帮助开发者快速上手。 9. 内核提供者（Kernel Providers）：内核提供者是一个抽象层，负责查找和启动内核。Jupyter_client包含了多种内核提供者，可以根据不同的环境和需求选择合适的内核。 10. API参考：Jupyter_client API文档详细介绍了如何发现内核（kernelspec）、启动和停止内核（manager）、以及与内核通信（client）的方法。 `jupyter-client`是开发人员和研究人员与Jupyter内核进行交互的核心工具，它支持了丰富的功能，如代码执行、输出捕获、内核管理，以及自定义扩展，极大地促进了数据分析和科学计算的交互性。

jupyter_client Documentation, Release 6.0.0.dev

• A shared key (typically the key ﬁeld of a connection ﬁle)

• The serialized header dict

• The serialized parent header dict

• The serialized metadata dict

• The serialized content dict

In Python, this is implemented via:

# once:

digester = HMAC(key, digestmod=hashlib.sha256)

# for each message

d = digester.copy()

for serialized_dict in (header, parent, metadata, content):

d.update(serialized_dict)

signature = d.hexdigest()

After the signature is the actual message, always in four frames of bytes. The four dictionaries that compose a message

are serialized separately, in the order of header, parent header, metadata, and content. These can be serialized by any

function that turns a dict into bytes. The default and most common serialization is JSON, but msgpack and pickle are

common alternatives.

After the serialized dicts are zero to many raw data buffers, which can be used by message types that support binary

data, which can be used in custom messages, such as comms and extensions to the protocol.

1.6 Python API

As messages are dicts, they map naturally to a func(

kw) call form. We should develop, at a few key points,

functional forms of all the requests that take arguments in this manner and automatically construct the necessary dict

for sending.

In addition, the Python implementation of the message speciﬁcation extends messages upon deserialization to the

following form for convenience:

{

'header' : dict,

# The msg's unique identifier and type are always stored in the header,

# but the Python implementation copies them to the top level.

'msg_id' : str,

'msg_type' : str,

'parent_header' : dict,

'content' : dict,

'metadata' : dict,

}

All messages sent to or received by any IPython process should have this extended structure.

1.7 Messages on the shell (ROUTER/DEALER) channel

1.7.1 Request-Reply

In general, the ROUTER/DEALER sockets follow a request-reply pattern:

1.6. Python API 7

jupyter_client Documentation, Release 6.0.0.dev

The client sends an <action>_request message (such as execute_request) on its shell (DEALER) socket.

The kernel receives that request and immediately publishes a status: busy message on IOPub. The kernel then

processes the request and sends the appropriate <action>_reply message, such as execute_reply. After

processing the request and publishing associated IOPub messages, if any, the kernel publishes a status: idle

message. This idle status message indicates that IOPub messages associated with a given request have all been re-

ceived.

All reply messages have a 'status' ﬁeld, which will have one of the following values:

• status='ok': The request was processed successfully, and the remaining content of the reply is speciﬁed in

the appropriate section below.

• status='error': The request failed due to an error. When status is ‘error’, the usual content of a suc-

cessful reply should be omitted, instead the following ﬁelds should be present:

{

'status' : 'error',

'ename' : str, # Exception name, as a string

'evalue' : str, # Exception value, as a string

'traceback' : list(str), # traceback frames as strings

}

• status='abort': This is the same as status='error' but with no information about the error. No

ﬁelds should be present other that status.

Changed in version 5.1: status='abort' has not proved useful, and is considered deprecated. Kernels should

send status='error' instead.

1.7.2 Execute

This message type is used by frontends to ask the kernel to execute code on behalf of the user, in a namespace reserved

to the user’s variables (and thus separate from the kernel’s own internal code and variables).

Message type: execute_request:

content = {

# Source code to be executed by the kernel, one or more lines.

'code' : str,

# A boolean flag which, if True, signals the kernel to execute

# this code as quietly as possible.

# silent=True forces store_history to be False,

# and will

not

# - broadcast output on the IOPUB channel

# - have an execute_result

# The default is False.

'silent' : bool,

# A boolean flag which, if True, signals the kernel to populate history

# The default is True if silent is False. If silent is True, store_history

# is forced to be False.

'store_history' : bool,

# A dict mapping names to expressions to be evaluated in the

# user's dict. The rich display-data representation of each will be evaluated after

˓→execution.

# See the display_data content for the structure of the representation data.

'user_expressions' : dict,

(continues on next page)

8 Chapter 1. Messaging in Jupyter

jupyter_client Documentation, Release 6.0.0.dev

(continued from previous page)

# Some frontends do not support stdin requests.

# If this is true, code running in the kernel can prompt the user for input

# with an input_request message (see below). If it is false, the kernel

# should not send these messages.

'allow_stdin' : True,

# A boolean flag, which, if True, does not abort the execution queue, if an exception

˓→is encountered.

# This allows the queued execution of multiple execute_requests, even if they

˓→generate exceptions.

'stop_on_error' : False,

}

Changed in version 5.0: user_variables removed, because it is redundant with user_expressions.

The code ﬁeld contains a single string (possibly multiline) to be executed.

The user_expressions ﬁeld deserves a detailed explanation. In the past, IPython had the notion of a prompt

string that allowed arbitrary code to be evaluated, and this was put to good use by many in creating prompts that

displayed system status, path information, and even more esoteric uses like remote instrument status acquired over the

network. But now that IPython has a clean separation between the kernel and the clients, the kernel has no prompt

knowledge; prompts are a frontend feature, and it should be even possible for different frontends to display different

prompts while interacting with the same kernel. user_expressions can be used to retrieve this information.

Any error in evaluating any expression in user_expressions will result in only that key containing a standard

error message, of the form:

{

'status' : 'error',

'ename' : 'NameError',

'evalue' : 'foo',

'traceback' : ...

}

Note: In order to obtain the current execution counter for the purposes of displaying input prompts, frontends may

make an execution request with an empty code string and silent=True.

Upon completion of the execution request, the kernel always sends a reply, with a status code indicating what happened

and additional data depending on the outcome. See below for the possible return codes and associated data.

Jupyter客户端：与内核交互的Python API

CodeReview工具Jupiter

Jupyter 无法下载文件夹如何实现曲线救国

PyPI 官网下载 | jupyter_client-5.0.1.tar.gz

ERROR: Could not find a version that satisfies the requirement jupyter-core>=4.6.0 (from jupyter-client->ipykernel) (from versions: none)

nbclient 0.5.3 has requirement jupyter-client>=6.1.5, but you have jupyter-client 6.1.1

ERROR: No matching distribution found for jupyter-core>=4.6.0 (from jupyter-client->ipykernel)

linux怎么卸载jupyter notebook

vscode配置jupyter环境

最新资源