You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
RectangleSelector examples don't run in notebooks #11201
You don’t usually need to call show in notebooks. The examples are meant to work standalone. While it’s a bit confusing to notebook users it’s not particularly a bug. Is there some way we can make the difference between notebooks and other backends more straightforward?
Not calling show does not make it work.
Since the gallery-example contains a "download jupyter notebook" button, it would make sense if the notebook actually works :)
Maybe this is not just a documentation issue, but a bug?
Events, connected using fig.canvas.mpl_connect(...), work fine in notebooks without a blocking show()..
As I am diggin into this things are starting to get hairy.
These are results using the example from the API doc:
nbagg:
With nbagg it never works (no blocking, no callback to onselect).
tk
With %matplotlib tk and plt.show(block=True), the code cell will run the first time and block until the figure is closed. The second time I run the cell and close the figure, the cell will keep blocking forever.
qt
With %matplotlib qt and plt.show(block=True), the code cell will run the first time and block until the figure is closed. The second time I run the cell and close the figure, the cell will not block.
In the terminal running Jupyter, I get: QCoreApplication::exec: The event loop is already running
Maybe there is the need to be more specific here. Which jupyter version, which IPython version, which matplotlib version are in use? What exactly does not work? I cannot reproduce this and everything works fine when using %matplotlib notebook.
I do agree that it is pretty useless to have the notebook with %matplotlib inline for an interactive example. I fear there is little one can do, as those are automatically generated (unless one want to change them all to notebook).
What does "to block" actually mean for a jupyter notebook?
How would you know the function does not run?
So I was testing with IPython 5.3.0, Jupyter 4.4.1, matplotlib 2.2.2. I replaced the first line of the notebook with %matplotlib notebook. I then restarted the kernel and ran the notebook.
In the output I can draw rectangles as desired.
I do not observe any difference between plt.show() and plt.show(block=True).
But the callback function (line_select_callback) is called as expected in both cases.
There is no printed output, simply because print wouldn't work inside the already created output section (or is this different in IPython 6?).
Ernest:
In a notebook, a blocking function means means that the cell does not finish executing. show(block=True) should keep the cell "running" until the figure is closed.
You are right. The callback does run, but does not print. I guess this is not possible. Sorry for the confusion on my part.
This leaves only the problem of inconsistent behaviour of show(block=True) and a documentation issue :)
In a notebook, a blocking function means means that the cell does not finish executing. show(block=True) should keep the cell "running" until the figure is closed.
Do you mean that if you click on "Run All", cells further down would not be executed? I cannot reproduce this: independent on plt.show() or plt.show(block=True) all cells will be executed in my case. @sorenrasmussen Is this different for you?
I think the question here is really:
Would there be a difference between plt.show() and plt.show(block=True) from within matplotlib? And if so how does it look like and where does it come from?
Finally, is there anything the matplotlib documentation can do not to trap people into running the notebooks from the example section, which have simply not been designed for or ever been tested on jupyter?
@ImportanceOfBeingErnest Correct, cells further down should not be executed if a function (and thereby also the cell where it was run) is blocking. Just like any other Python code.
@tacaswell Unfortunately, the rectangleselector is quite slow and a bit buggy with nbagg, at least on my setup. For example, if I mark rectangles quickly in succession, the "old" rectangles sometimes stay partly visible
Sorry, I may have missed that, but are they executed or are they not executed when you use plt.show(block=True)? As said, at the moment I do not see any difference. The question is if you see a difference between plt.show() and plt.show(block=True). This is primarily independent of what you think should happen, which is a thing to be discussed further once the current behaviour is clear.
plt.show() never blocks. This is as expected. plt.show(block=True) blocks sometimes, depending on the backend and whether the cell has been run before or not (see above). I would expect it to block every time, for any backend (maybe except inline), until the figure is closed.
I am still sceptical. Looking at the source code of the nbagg backend there should not be any difference between plt.show() and plt.show(block=True), because the argument block is never actually used. This is consistent with what I observe running the code in a jupyter notebook.
So if someone observes a difference, it should be well described, best without the use of qualifiers like "expected" or "works fine" but rather in a clear descritive way, and best without using the verb "to block" itself.
A table like
Jupyter notebook backend: This is feature request to have a blocking behaviour in the notebook. This might in general be hard to achieve due to the connections to the server.
In addition there might be a bug in the qt and tk backends when being run from within jupyter. I cannot reproduce this either, but that probably has different reasons out of the scope of this question.
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
Activity
jklymak commentedon May 8, 2018
You don’t usually need to call show in notebooks. The examples are meant to work standalone. While it’s a bit confusing to notebook users it’s not particularly a bug. Is there some way we can make the difference between notebooks and other backends more straightforward?
sorenrasmussen commentedon May 8, 2018
Not calling
showdoes not make it work.Since the gallery-example contains a "download jupyter notebook" button, it would make sense if the notebook actually works :)
sorenrasmussen commentedon May 8, 2018
Maybe this is not just a documentation issue, but a bug?
Events, connected using
fig.canvas.mpl_connect(...), work fine in notebooks without a blockingshow()..jklymak commentedon May 8, 2018
Which backend are you using? Does nbagg work ok? Ie %matplotlib notebook
sorenrasmussen commentedon May 8, 2018
I have tried with Qt, TK and nbagg.
As I am diggin into this things are starting to get hairy.
These are results using the example from the API doc:
nbagg:
With
nbaggit never works (no blocking, no callback toonselect).tk
With
%matplotlib tkandplt.show(block=True), the code cell will run the first time and block until the figure is closed. The second time I run the cell and close the figure, the cell will keep blocking forever.qt
With
%matplotlib qtandplt.show(block=True), the code cell will run the first time and block until the figure is closed. The second time I run the cell and close the figure, the cell will not block.In the terminal running Jupyter, I get:
QCoreApplication::exec: The event loop is already runningImportanceOfBeingErnest commentedon May 8, 2018
Maybe there is the need to be more specific here. Which jupyter version, which IPython version, which matplotlib version are in use? What exactly does not work? I cannot reproduce this and everything works fine when using
%matplotlib notebook.I do agree that it is pretty useless to have the notebook with
%matplotlib inlinefor an interactive example. I fear there is little one can do, as those are automatically generated (unless one want to change them all tonotebook).sorenrasmussen commentedon May 8, 2018
Software:
What works:
I can draw rectangles in the figure.
What doesn't work:
When
plt.show()does not block, theonselectfunction does not run.plt.show(block=True)does not consistently cause blocking behaviour.I get no Python errors.
ImportanceOfBeingErnest commentedon May 8, 2018
What does "to block" actually mean for a jupyter notebook?
How would you know the function does not run?
So I was testing with IPython 5.3.0, Jupyter 4.4.1, matplotlib 2.2.2. I replaced the first line of the notebook with
%matplotlib notebook. I then restarted the kernel and ran the notebook.In the output I can draw rectangles as desired.
I do not observe any difference between
plt.show()andplt.show(block=True).But the callback function (
line_select_callback) is called as expected in both cases.There is no printed output, simply because
printwouldn't work inside the already created output section (or is this different in IPython 6?).tacaswell commentedon May 8, 2018
The print is likely coming out in the terminal where you started the notebook server....
tacaswell commentedon May 8, 2018
I also strongly recommend against using notebooks + GUI backends, there are too many event loops running.
sorenrasmussen commentedon May 8, 2018
Ernest:
In a notebook, a blocking function means means that the cell does not finish executing. show(block=True) should keep the cell "running" until the figure is closed.
You are right. The callback does run, but does not print. I guess this is not possible. Sorry for the confusion on my part.
This leaves only the problem of inconsistent behaviour of show(block=True) and a documentation issue :)
ImportanceOfBeingErnest commentedon May 8, 2018
Do you mean that if you click on "Run All", cells further down would not be executed? I cannot reproduce this: independent on
plt.show()orplt.show(block=True)all cells will be executed in my case.@sorenrasmussen Is this different for you?
I think the question here is really:
plt.show()andplt.show(block=True)from within matplotlib? And if so how does it look like and where does it come from?sorenrasmussen commentedon May 9, 2018
@ImportanceOfBeingErnest Correct, cells further down should not be executed if a function (and thereby also the cell where it was run) is blocking. Just like any other Python code.
@tacaswell Unfortunately, the rectangleselector is quite slow and a bit buggy with nbagg, at least on my setup. For example, if I mark rectangles quickly in succession, the "old" rectangles sometimes stay partly visible
ImportanceOfBeingErnest commentedon May 9, 2018
Sorry, I may have missed that, but are they executed or are they not executed when you use
plt.show(block=True)? As said, at the moment I do not see any difference. The question is if you see a difference betweenplt.show()andplt.show(block=True). This is primarily independent of what you think should happen, which is a thing to be discussed further once the current behaviour is clear.sorenrasmussen commentedon May 9, 2018
plt.show()never blocks. This is as expected.plt.show(block=True)blocks sometimes, depending on the backend and whether the cell has been run before or not (see above). I would expect it to block every time, for any backend (maybe exceptinline), until the figure is closed.ImportanceOfBeingErnest commentedon May 9, 2018
I am still sceptical. Looking at the source code of the nbagg backend there should not be any difference between
plt.show()andplt.show(block=True), because the argumentblockis never actually used. This is consistent with what I observe running the code in a jupyter notebook.So if someone observes a difference, it should be well described, best without the use of qualifiers like "expected" or "works fine" but rather in a clear descritive way, and best without using the verb "to block" itself.
A table like
could then help to sort this out.
sorenrasmussen commentedon May 9, 2018
@ImportanceOfBeingErnest
%matplotlib notebook
plt.show(): cell execution finishes.plt.show(block=True): cell execution finishesplt.show(): cell execution finishes.plt.show(block=True): cell execution finishes%matplotlib tk
plt.show(): cell execution finishes.plt.show(block=True): cell keeps running until figure close.plt.show(): cell execution finishes.plt.show(block=True): cell keeps running indefinitely.%matplotlib qt
plt.show(): cell execution finishes.plt.show(block=True): cell keeps running until figure close.plt.show(): cell execution finishes.plt.show(block=True): cell execution finishes.ImportanceOfBeingErnest commentedon May 9, 2018
So to summarize,
notebookbackend: This is feature request to have a blocking behaviour in the notebook. This might in general be hard to achieve due to the connections to the server.github-actions commentedon May 6, 2023
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!