Include example of ipython_blocking

[ianhi]

https://github.com/kafonek/ipython_blocking seems to be the only way to wait for a user interaction on the frontend. Which is one of the most common requests on the jupyter-widgets gitter channel so it should at least be mentioned somewhere in this repo and perhaps even have an example where a widget demonstrates wrapping it in a function.

attn: @kafonek does this make sense or is kafonek/ipython_blocking#7 intractable enough that ipython_blocking shouldn't be recommended?

[kafonek]

Thanks for flagging me @ianhi -- it's worth tagging @jasongrout here too, if not Min or Sylvain or others. ipython_blocking is a pretty fragile library since it is hacking get_ipython.kernel.shell_handlers, and it's hard to imagine what that will effect in non-vanilla Jupyter deployments. When it works, great. When it doesn't, you fall into a deep rabbit hole pretty quickly. I still don't know what's going on with ipyfilechooser in your linked issue although I wouldn't say that the ipyfilechooser issue is a huge issue, as I don't see that widget used in an overwhelming number of Notebooks.

I'm happy to help write examples of ipython_blocking besides the provided README if you'd like. In our corporate environment, it did not gain widespread traction as the go-to library for blocking. Rather, Notebook developers continued to write callback functions or refactored very large UI-component Notebooks into traditional web applications.

More background reading for anyone coming to this issue -

• https://discourse.jupyter.org/t/thoughts-and-experiences-from-using-jupyter-in-enterprise/2572 - some motivation on why I tried to build ipython_blocking to begin with
• https://github.com/kafonek/notebook_restified - follow-on project to ipython_blocking, similarly fragile / unused
• challenges with readability and application logic with interactivity pangeo-data/jupyter-earth#35 - Pangeo issue on readability issues that inspired ipython_blocking
• Run control channel in separate thread ipython/ipykernel#585 -- new (Jan 20201) channels aimed at debugger, could this pattern separate widget comms from cell execution comms?

cc @jeffyjefflabs @lheagy @somedave

[ianhi]

what's going on with ipyfilechooser in your linked issue although I wouldn't say that the ipyfilechooser issue is a huge issue, as I don't see that widget used in an overwhelming number of Notebooks.

In crahan/ipyfilechooser#36 (comment) you said "it looks like the memory leak is happening with pretty much any widget. " so I was worried that this is not contained to ipyfilechooser

channels aimed at debugger, could this pattern separate widget comms from cell execution comms?

This was mentioned in an ipywidgets meeting at some point. But I don't think it was ever followed up on. It seems unlikely to happen (I think?) as it's a big change (I think?).

[kafonek]

Yep fair point @ianhi . I suppose I would say that "blocking widgets" is an unsolved problem then. Putting application logic in callback functions has its drawbacks. ipython_blocking has numerous limitations. There's no lack of community desire for the feature though.