Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include example of ipython_blocking #17

Open
ianhi opened this issue Mar 30, 2021 · 3 comments
Open

Include example of ipython_blocking #17

ianhi opened this issue Mar 30, 2021 · 3 comments

Comments

@ianhi
Copy link
Owner

ianhi commented Mar 30, 2021

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
Copy link

kafonek commented Mar 30, 2021

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 -

cc @jeffyjefflabs @lheagy @somedave

@ianhi
Copy link
Owner Author

ianhi commented Apr 1, 2021

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
Copy link

kafonek commented Apr 1, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants