-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Adds error handling around install_repl_displayhook #25870
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
Adds error handling around install_repl_displayhook #25870
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for opening your first PR into Matplotlib!
If you have not heard from us in a while, please feel free to ping @matplotlib/developers
or anyone who has commented on the PR. Most of our reviewers are volunteers and sometimes things fall through the cracks.
You can also join us on gitter for real-time discussion.
For details on testing, writing docs, and our review process, please see the developer guide
We strive to be a welcoming and open project. Please follow our Code of Conduct.
lib/matplotlib/pyplot.py
Outdated
install_repl_displayhook() | ||
try: | ||
install_repl_displayhook() | ||
except ImportError as err: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we catch the NotImplemented
error here instead and make no changes to install_repl_displayhook
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I changed it! In light of your next comment -- is this still relevant in general (should I amend my PR)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think the technical question is if we
- eat the error
- warn
- re-raise
ImportError
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clearly I'm no authority on this, but warning and re-raising seem pretty logical to do because it just crashes otherwise.
I also didn't fully understand your comment -- like why should there be no GUI at all with block=True/sleep enabled. The couple of examples I tried all seemed to work (switching to a different backend and continuing as intended). I'm very likely missing something, but is the expected behavior here something different?
Now that I see this implemented as I described I'm no longer sure this is best approach 😞 . I still think the analysis of the problem in #23770 (comment) is correct, however what I did not consider when I wrote that is that it only applies if the user wants to do On the other hand if we just catch and eat the With the plain Python shell this sort of "un-managed" situation is possible so from a parity point of view preventing it is bad. On the other hand, currently the GUI backends do not work with this version of the IPython shell so we are not actually taking anything away, but are making it so things will automatically import and do something sensible. I can see arguments both ways and think either one would be acceptable, but we should consider both options. |
So with this change I think it will fallback to
work. On the other hand, we could just eat the exception and give the user a partially functional GUI. |
Hi @turnipseason @tacaswell do we need more discussion here or is there a clear path forward? @turnipseason do you need help with the current test failures? |
Hi @melissawm ! Sorry for not replying sooner. I tried understanding what's going on but still don't quite get it, so I'm not sure I can contribute much to the discussion, unfortunately. When I tried running it, both (eating/not eating the exception) ways worked just fine and neither defaulted to the non-interactive background. They also never seemed to enter the interactive python mode though (I couldn't type in the console, even though the input was captured and shown after I closed the GUI), so I'm not sure if I just wrote something incorrectly. With regards to the test failures -- yes, I think I do. |
yes you can use I would also perhaps suggest using the |
673da5e
to
e98d502
Compare
Did the rebase, which was just caused by a comment being reflowed adjacent to some changed lines |
Test failures on azure macos are the newly added test
response = _run_helper(_fallback_check, timeout=_test_timeout) | ||
assert response != subprocess.CalledProcessError |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The run helper passes check=True
, which causes CalledProcessError
to be raised; I don't understand why this is checking the return value, which should be a subprocess.CompletedProcess
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. I just thought we had to check for it. Should I leave the test at this, then? It seems to do the same thing (fail without the fix, pass with the fix).
def test_fallback_to_different_backend():
pytest.importorskip("IPython")
_run_helper(_fallback_check, timeout=_test_timeout)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All exceptions are errors; the assert
can never be False, so there's no need for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok then, thank you, I'll leave it without the assert!
Test failures on Azure MacOS are still the newly added test in the latest revision. Additionally, needs a rebase for the meson build system change to fix Circle. |
Do you have any thoughts on this PR, @ianthomas23? |
I think it is a somewhat unusual use case that would be reasonable to "won't fix" but given that the fix is simple, localised and evidently a good thing to do anyway then I would approve it. It needs a rebase but that looks relatively straightforward. One complication is that there is another unprotected use of matplotlib/lib/matplotlib/pyplot.py Lines 724 to 728 in 9489b93
and we cannot repeat the fix here as we are not switching a backend. But I don't think it should stop this PR. |
# This is a combination of 3 commits. Fixes the issue 23770 and adds a test in test_backends_interactive.py Changed the test to skip when IPython can't be imported and use _run_helper for the subprocess. Removed the redundant assert statement.
5c468c3
to
321b769
Compare
OK, then I've rebased and squashed. |
I'd be happy to approve this but there are some CI failures that may or may not be related. |
It looks like the new test is hitting the long-standing actions/setup-python#649 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved as CI failure unrelated.
PR summary
Closes #23770. Starting an ipython session with InteractiveShell led to a crash with NotImplementedError being raised. An ImportError needed to be raised from that, allowing for continuation with a different backend.
PR checklist
[N/A] Plotting related features are demonstrated in an example
[N/A] New Features and API Changes are noted with a directive and release note
[N/A] Documentation complies with general and docstring guidelines