Handle `execute_request_impl(user_expressions = )`

[romainfrancois]

Not sure what user_expressions = is

[adamblake]

I did a little research on this, and hope it helps you out!

In my understanding they are lightweight expressions that are run after the main request code is executed. They are run against the state of the user's kernel, but they shouldn't affect the state of the kernel. An example would be something like a front-end tool that requests the value of a variable after it is assigned so that it can be inspected:

Request:

{
  "code": "x = 10",
  "silent": false,
  "store_history": true,
  "user_expressions": {
    "inspect_x": "x"
  }
}

Reply:

{
  "header": {
    "msg_type": "execute_reply",
    ...
  },
  "parent_header": ...,
  "metadata": {},
  "content": {
    "status": "ok",
    "execution_count": 1,
    "payload": [],
    "user_expressions": {
      "inspect_x": {
        "status": "ok",
        "data": {
          "text/plain": "10"
        },
        "metadata": {}
      }
    }
  }
}

A use-case I found is in MyST Inline Expressions. They have an open PR for this here in IRKernel that hasn't been touched in a few months: IRkernel/IRkernel#742

The Jupyter Client documentation also gives another use-case of a front-end requesting data to get information for prompts. I found it a little confusing, but here it is:

The user_expressions field 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' : ...
}