Huh, as a somewhat knowledgeable user, I had zero idea thatpyplot was in charge of GUI integration. When I first read the above I wasn't clear why we don't just have or addfig.show(), which I guess would mean we would need a way for figures to get their own manager.

So, I think that we can go ahead and try to disassociate the GUI integration from pyplot, or we can just accept that some basic things get done in pyplot that have nothing to do w/ thegcf integration.

The problem offig.show() is, how would that work if you want to show two figures? (basically you'd want the first show() to not block (so that you can reach the second show(), but the second one to block (so that the process doesn't terminate immediately). As far as I can see, having a single function that takes as parameter a list of figures to be shown is necessary to handle this (not so rare) case.

Forgetting about our current concept of "block", I'd expect you couldshow as many figures as you want and the process wouldn't end until you manually close all the figures.

So effectively figure.show() would behave like plt.show(block=False),except that the process does not end at the end of the program? I guess that can work, too.

So effectively figure.show() would behave like plt.show(block=False),except that the process does not end at the end of the program? I guess that can work, too.

Thats how I'd expect a GUI to behave, but no doubt I'm missing a subtlety somewhere...

figure.show() doesn't start or run an event loop, whileplt.show() does (or in case ofion emulates one), right? So wouldplt.show([fig1]) start an event loop or not and would it be blocking in case ofioff?

Would

fig1 = plt.figure()fig2 = mpl.figure.Figure()plt.show([fig2])

be showing fig1 as well?

fig.show() can take care of spinning up an event loop if none is running yet, that's not really a problem.

Whether a call toshow() would implicitly also include all pyplot-generated figures is just a design choice that needs to be made, I would prefer not but either way is fine.

I think we should in general prepare for a way to reshow closed pyplot figures. This is currently one of the most annoying restrictions users face, i.e.

fig, ax = plt.subplots()ax.plot(...)plt.show() # Figure is shown, User closes it.# At this point there is no way[*] to show the figure again.# Suggestion would be toplt.show(figures=[fig])

import matplotlib.pyplot as pltdef reshow(fig):    import importlib    import matplotlib.backends    import matplotlib.backend_bases    backend_mod = importlib.import_module(f"matplotlib.backends.backend_{plt.get_backend().lower()}")    Backend = type("Backend", (matplotlib.backends._Backend,), vars(backend_mod))    fm = Backend.new_figure_manager_given_figure(1, fig)    matplotlib.backend_bases.Gcf.set_active(fm)    plt.show()    fig1, ax1 = plt.subplots()ax1.plot([1,2], label="ABC")plt.show() #Now reshow the figurereshow(fig1)

I’m not understanding the situation where the user expects a figure to be able to be reopened. If I click the little red x I expect whatever was there to disappear. You could argue that it could prompt to save but otherwise?

Sure, you could register a callback to aclose_event that pickles the figure before destroying the manager, such that if unpickled it can be shown again. That is equally cumbersome.

By "save", I meant saving as an image.

I'm 👎 on saving figures so they can be resurrected as an interactive thing later. At the most practical, such figures won't survive changes of matplotlib versions if any internal organization of the objects has changed. Pickle, itself, became incompatible between py2.x and py3.x (I'll never willingly use pickle again). Overall it just seems like a lot of hassle. And why? Users should be able to re-create the figure from their script and not rely on manual fiddling with the GUI or a bunch of manual typing in the REPL.

I admit this is not a universal opinion, but I think having figures that robustly resurrect themselves is really hard from a developers perspective, and not a good idea from the user's perspective.

Matplotlib supports pickling of figures just fine (of course in- and output versions must be the same!) and there is a bunch of tests for that, so this is an existing feature, not for debate here. I only mentionned it as workaround for reshowing a figure. And I mentionned the desire for reshowing a figure here, because I think it needs to be taken into account when designingplt.show(figures).

@ImportanceOfBeingErnest re-show()ing a figure basically just works with this PR.
Actually there's a bug whenclosing a qt figurefor the second time with a key shortcut ("q") because the private _destroying attribute is not cleared out, and I guess othermanagers may have similar issues, but on pyplot's side I think this works fine.

I see. I was missing the fact that apparently closed figures keep their manager. But that wouldn't be the case for a pickled figure, right?

import pickleimport matplotlib.pyplot as pltfig, ax = plt.subplots()ax.plot([12, 13], label="ABCDE")plt.close(fig)with open('fig.pickle', 'wb') as f:    pickle.dump(fig, f)with open('fig.pickle', 'rb') as f:    fig1 = pickle.load(f)plt.show(figures=[fig1])

Traceback (most recent call last):  File "untitled3.py", line 20, in <module>    plt.show(figures=[fig1])  File "d:\***\matplotlib\lib\matplotlib\pyplot.py", line 262, in show    return _show(*args, **kw)  File "d:\***\matplotlib\lib\matplotlib\cbook\deprecation.py", line 409, in wrapper    return func(*args, **kwargs)  File "d:\***\matplotlib\lib\matplotlib\backend_bases.py", line 3278, in show    if figures is not None else Gcf.get_all_fig_managers())  File "d:\***\matplotlib\lib\matplotlib\backend_bases.py", line 3277, in <listcomp>    managers = ([figure.canvas.manager for figure in figures]AttributeError: 'NoneType' object has no attribute 'manager'

Not sure if it should work though.

A manager is (holding) a GUI widget, so it's going to be tricky to pickle :p
The relevant piece of code is basically at

• don't create a manager
• create a manager, but don't register with pyplot
• create a manager, and register to pyplot and show the figure

but this can clearly be done separately from (after?) this PR.

Yes pickling is again a bad example, I suppose. Let's just take

plt.show(figures=[plt.Figure()])

which will also not have a manager. If that is expected, maybe a better error message should tell people exactly which figures they can show this way.

That should just be a matter of callingnew_figure_manager_given_figure(fig), which can be done automatically withinshow() for managerless figures. Well, that adopts the figure into Gcf so we need to take it out of Gcf (so that again it can get properly gc'd), but that's the idea. (But note that the original intent was for people to useplt.new_figure_not_globally_registered("title") (which would create a manager) instead of the Figure constructor directly -- but I guess we may as well avoid adding a new API).

I am 👍 on this.

Semi OT: While I see the reason behind this approach,plt.show([fig]) is still a crutch, andfig.show() would be much more intuitive from a user perspective.

The problem offig.show() is that (per the above) it's not really clear whether we want that to default to blocking or not.

I know it's not that simple :sad:.

Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it.

Mplgui basically solves this issue. Now we just need a path to merging it!

Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it.

This is basically tracked by the mplgui work.