object_inspect may call user-defined functions that wedge the kernel

[CSEMike]

Actions that induce object inspection, e.g., shift-tab after a variable, may call user-defined functions that take a long time to complete. When that happens, the kernel is wedged. Subsequent code execution blocks waiting for the inspect reply, kernel interrupt doesn't unblock, meaning that a kernel process restart is required to proceed.

An example follows:

This example shows the back-to-back completion time for an object inspect triggered by shift-tab. I recorded the demo from a Jupyterlab frontend started on try.jupyter.org. The issue applies to vanilla Jupyter as well.

In this example, Slow is an object with a __repr__ that takes 1 second. __repr__ seems to be called multiple times during inspection, meaning that the end-to-end time to inspect an object with a 1 second __repr__ is ~10 seconds.

Of course, increasing the sleep increases the delay.

I suspect there's a fundamental tradeoff between the information available in object inspection and reliability. To avoid becoming wedged, object inspection and code completion should avoid calling any user-defined functions. But, that will limit available information.

[minrk]

To avoid becoming wedged, object inspection and code completion should avoid calling any user-defined functions

This is by design, and how Python and IPython generally work. I don't think this is something that we should change. It is part of what's fundamentally useful about IPython when compared to static analysis.

__repr__ seems to be called multiple times during inspection

If there is a change to make here, it might be attempting to cache certain method calls to reduce the number of times they are called during a single inspection. That said, I would expect a slow repr to have loads of problems, anyway. I don't believe inspecting an instance without evaluating its repr is a good thing to do, though.

Subsequent code execution blocks waiting for the inspect reply, kernel interrupt doesn't unblock, meaning that a kernel process restart is required to proceed.

This is something we should look at. Since, as you have pointed out, inspection really is an arbitrary execution, it should be interruptible just like other executions.