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 doplt.ion() and work in "interactive mode". If they are happy to not have windows pop-up and be live while they type (and either useplt.show(block=True) orplt.sleep(10) to get temporarily live figures) then this change will prevent users from getting GUIs at all.

On the other hand if we just catch and eat theNotImplemented exception inswitch_backends (maybe printing a warning) then we enable users use GUI backends with this limited IPython shell, even if its usage is degraded.

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 toagg because we can get IPython to setup up the input hook so that

plt.ion()plt.show(block=False)

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@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.
They seem to be coming from the tests I wrote, since it calls for IPython in the subprocess and the tests fail with a ModuleNotFoundError because there's no IPython. Should I check for the existence of IPython in the subprocess and skip the test somehow if is isn't found since this issue concerns IPython in the first place? Or rewrite them completely?

@turnipseason

yes you can usepytest.importorskip("IPython")

I would also perhaps suggest using the_run_helper for running your code as a subprocess, that will allow the code to look like a normal python function, rather than being included as strings.

Did the rebase, which was just caused by a comment being reflowed adjacent to some changed lines

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?

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 ofinstall_repl_displayhook inpyplot.ion():

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-standingactions/setup-python#649