Simpler "pyplotless" use pattern. #14024

anntzer · 2019-04-23T21:06:36Z

cf. mailing list discussion on garbage collection.

Right now, if one does not want to use pyplot (e.g., batch use), one can
do

from matplotlib.figure import Figure
fig = Figure(); ... <plot> ...; fig.savefig(...)

but it is impossible to show() the figure interactively (i.e. pyplot
cannot "adopt" the figure) e.g. for debugging.

This patch makes it possible: with it, one can do

fig = plt.new_figure_manager(num).canvas.figure
... <plot> ...
fig.savefig()
plt.show(figures=[fig])

Note that this does not register the figure with pyplot; in particular
fig is garbage-collected when it goes out of scope, does not
participate in gcf(); etc. So this is "pyplotless" in the sense that
there is no global figure registry anymore, but pyplot still stays in
charge of the GUI integration.

Obviously the plt.new_figure_manager(num).canvas.figure expression
could / should be encapsulated in a helper function, up to bikeshedding.

The num parameter is needed as matplotlib currently uses it to set the
figure title, but that can easily be made optional too.

Finally note that plt.show([fig]) would be a nicer API, but right now
the first parameter to plt.show is block, which is undergoing
transition to kwonly.

IOW the end-goal would be e.g.

# intentionally terrible name as placeholder :)
fig = plt.new_figure_not_globally_registered("some title")
... <plot> ...
fig.savefig()
plt.show([fig])

some more thoughts:
While this "logically" belongs to pyplot in the sense that pyplot is in charge of the GUI integration, this doesn't actually interact with any of the pyplot plotting functions that operate on gcf()/gca(), so perhaps it may be better (to avoid user confusion) to have a separate submodule just hosting new_figure_not_globally_registered and show (in which case the latter could have the "better" API show([fig], *, block=False) immediately).

Currently the num argument to new_figure_manager needs to be an int, but note that plt.figure() supports both int and string and the logic to support both can easily be pushed down to new_figure_manager... but preferably after merging #13569 and #13581.

PR Summary

PR Checklist

Has Pytest style unit tests
Code is Flake 8 compliant
New features are documented, with examples if plot related
Documentation is sphinx and numpydoc compliant
Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

jklymak · 2019-04-24T14:49:23Z

Huh, as a somewhat knowledgeable user, I had zero idea that pyplot was in charge of GUI integration. When I first read the above I wasn't clear why we don't just have or add fig.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/ the gcf integration.

anntzer · 2019-04-24T14:54:14Z

The problem of fig.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.

jklymak · 2019-04-24T15:06:31Z

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

anntzer · 2019-04-24T15:19:00Z

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.

jklymak · 2019-04-24T15:44:42Z

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...

ImportanceOfBeingErnest · 2019-04-24T15:53:37Z

figure.show() doesn't start or run an event loop, while plt.show() does (or in case of ion emulates one), right? So would plt.show([fig1]) start an event loop or not and would it be blocking in case of ioff?

Would

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

be showing fig1 as well?

anntzer · 2019-04-24T17:30:02Z

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 to show() 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.

ImportanceOfBeingErnest · 2019-09-18T18:16:57Z

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 to
plt.show(figures=[fig])

[*] "No way" in the sense of...

...you don't want to do this:

import matplotlib.pyplot as plt

def 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 figure
reshow(fig1)

jklymak · 2019-09-18T18:32:42Z

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?

ImportanceOfBeingErnest · 2019-09-18T18:48:32Z

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

jklymak · 2019-09-18T19:04:22Z

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.

ImportanceOfBeingErnest · 2019-09-18T19:13:02Z

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 designing plt.show(figures).

anntzer · 2019-09-19T13:33:08Z

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

ImportanceOfBeingErnest · 2019-09-19T21:05:13Z

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?

This is what happens

import pickle
import matplotlib.pyplot as plt

fig, 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])

gives

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.

anntzer · 2019-09-19T21:21:32Z

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

matplotlib/lib/matplotlib/figure.py

Line 2008 in db5fb66

if getattr(self.canvas, 'manager', None) \

and

matplotlib/lib/matplotlib/figure.py

Line 2037 in db5fb66

if restore_to_pylab:

-- note that the unpickler explicitly recreates a fresh manager if restore_to_pylab is set, and the pickler explicitly doesn't set it if the figure has been evicted from Gcf (as happens with close()).
Probably just a matter of replacing restore_to_pylab by a tristate for the behavior on unpickling:

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.

ImportanceOfBeingErnest · 2019-09-19T21:39:53Z

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.

anntzer · 2019-09-19T21:44:22Z

That should just be a matter of calling new_figure_manager_given_figure(fig), which can be done automatically within show() 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 use plt.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).

tacaswell · 2020-10-31T23:48:18Z

lib/matplotlib/backend_bases.py

        """
        Show all figures.

        `show` blocks by calling `mainloop` if *block* is ``True``, or if it
        is ``None`` and we are neither in IPython's ``%pylab`` mode, nor in
        `interactive` mode.
        """
-        managers = Gcf.get_all_fig_managers()
+        managers = ([figure.canvas.manager for figure in figures]


This should be more forgiving to canvases without managers?

I don't think ignoring (silently or not) figures we can't show because they have no manager is really helpful?

One idea would be to auto-setup a manager for them, though.

tacaswell · 2020-10-31T23:48:41Z

I am 👍 on this.

lib/matplotlib/backend_bases.py

timhoffm · 2020-11-01T00:46:33Z

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

anntzer · 2020-11-01T10:51:20Z

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

Right now, if one does not want to use pyplot (e.g., batch use), one can do from matplotlib.figure import Figure fig = Figure(); ... <plot> ...; fig.savefig(...) but it is impossible to show() the figure interactively (i.e. pyplot cannot "adopt" the figure) e.g. for debugging. This patch makes it possible: with it, one can do fig = plt.new_figure_manager(num).canvas.figure ... <plot> ... fig.savefig() plt.show(figures=[fig]) Note that this does *not* register the figure with pyplot; in particular *fig* is garbage-collected when it goes out of scope, does not participate in gcf(); etc. So this is "pyplotless" in the sense that there is no global figure registry anymore, but pyplot still stays in charge of the GUI integration. Obviously the `plt.new_figure_manager(num).canvas.figure` expression could / should be encapsulated in a helper function, up to bikeshedding. The `num` parameter is needed as matplotlib currently uses it to set the figure title, but that can easily be made optional too. Finally note that `plt.show([fig])` would be a nicer API, but right now the first parameter to plt.show is `block`, which is undergoing transition to kwonly. IOW the end-goal would be e.g. # intentionally terrible name as placeholder :) fig = plt.new_figure_not_globally_registered("some title") ... <plot> ... fig.savefig() plt.show([fig])

timhoffm · 2020-11-01T11:10:41Z

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

github-actions · 2023-06-14T02:01:50Z

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.

jklymak · 2023-06-14T02:26:15Z

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

github-actions · 2023-08-16T01:46:43Z

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.

anntzer · 2023-08-16T09:59:19Z

This is basically tracked by the mplgui work.

anntzer added topic: pyplot API status: needs comment/discussion needs consensus on next step labels Apr 23, 2019

anntzer added this to the v3.2.0 milestone Apr 23, 2019

anntzer force-pushed the unpyplot branch from 319c6bd to 2980caa Compare April 24, 2019 14:57

dstansby mentioned this pull request May 15, 2019

Fixes to .plot() (for Map) and .peek() (for all classes) sunpy/sunpy#3103

Merged

timhoffm modified the milestones: v3.2.0, v3.3.0 Aug 15, 2019

This was referenced Sep 5, 2019

Feature/improve visualization GAA-UAM/scikit-fda#159

Merged

Closing figures is done by number #15203

Closed

ImportanceOfBeingErnest mentioned this pull request Oct 1, 2019

Recommendation for using pyplot vs OOP API #15355

Closed

anntzer mentioned this pull request Jan 30, 2020

enable figures to be excluded from calls to show() #16377

Closed

QuLogic modified the milestones: v3.3.0, v3.4.0 May 2, 2020

anntzer mentioned this pull request Oct 31, 2020

Enh new figure function in backends #18852

Draft

7 tasks

tacaswell reviewed Oct 31, 2020

View reviewed changes

timhoffm reviewed Nov 1, 2020

View reviewed changes

lib/matplotlib/backend_bases.py Outdated Show resolved Hide resolved

anntzer force-pushed the unpyplot branch from 2980caa to cfd768e Compare November 1, 2020 10:52

QuLogic modified the milestones: v3.4.0, v3.5.0 Jan 21, 2021

anntzer mentioned this pull request Apr 14, 2021

Native support for showing OOP-created figures #19956

Open

jklymak marked this pull request as draft April 23, 2021 16:33

QuLogic modified the milestones: v3.5.0, v3.6.0 Aug 23, 2021

kalekundert mentioned this pull request Jan 31, 2022

wellmap.show(toml) prints map layout twice kalekundert/wellmap#19

Open

timhoffm modified the milestones: v3.6.0, unassigned Apr 30, 2022

story645 modified the milestones: unassigned, needs sorting Oct 6, 2022

github-actions bot added the status: inactive Marked by the “Stale” Github Action label Jun 14, 2023

github-actions bot removed the status: inactive Marked by the “Stale” Github Action label Jun 16, 2023

github-actions bot added the status: inactive Marked by the “Stale” Github Action label Aug 16, 2023

anntzer closed this Aug 16, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Simpler "pyplotless" use pattern. #14024

Simpler "pyplotless" use pattern. #14024

anntzer commented Apr 23, 2019 •

edited

Loading

jklymak commented Apr 24, 2019

anntzer commented Apr 24, 2019

jklymak commented Apr 24, 2019

anntzer commented Apr 24, 2019

jklymak commented Apr 24, 2019

ImportanceOfBeingErnest commented Apr 24, 2019

anntzer commented Apr 24, 2019

ImportanceOfBeingErnest commented Sep 18, 2019

jklymak commented Sep 18, 2019

ImportanceOfBeingErnest commented Sep 18, 2019

jklymak commented Sep 18, 2019

ImportanceOfBeingErnest commented Sep 18, 2019

anntzer commented Sep 19, 2019

ImportanceOfBeingErnest commented Sep 19, 2019

anntzer commented Sep 19, 2019 •

edited

Loading

ImportanceOfBeingErnest commented Sep 19, 2019

anntzer commented Sep 19, 2019 •

edited

Loading

tacaswell Oct 31, 2020

anntzer Nov 1, 2020 •

edited

Loading

tacaswell commented Oct 31, 2020

timhoffm commented Nov 1, 2020

anntzer commented Nov 1, 2020

timhoffm commented Nov 1, 2020

github-actions bot commented Jun 14, 2023

jklymak commented Jun 14, 2023

github-actions bot commented Aug 16, 2023

anntzer commented Aug 16, 2023

Simpler "pyplotless" use pattern. #14024

Simpler "pyplotless" use pattern. #14024

Conversation

anntzer commented Apr 23, 2019 • edited Loading

PR Summary

PR Checklist

jklymak commented Apr 24, 2019

anntzer commented Apr 24, 2019

jklymak commented Apr 24, 2019

anntzer commented Apr 24, 2019

jklymak commented Apr 24, 2019

ImportanceOfBeingErnest commented Apr 24, 2019

anntzer commented Apr 24, 2019

ImportanceOfBeingErnest commented Sep 18, 2019

jklymak commented Sep 18, 2019

ImportanceOfBeingErnest commented Sep 18, 2019

jklymak commented Sep 18, 2019

ImportanceOfBeingErnest commented Sep 18, 2019

anntzer commented Sep 19, 2019

ImportanceOfBeingErnest commented Sep 19, 2019

anntzer commented Sep 19, 2019 • edited Loading

ImportanceOfBeingErnest commented Sep 19, 2019

anntzer commented Sep 19, 2019 • edited Loading

tacaswell Oct 31, 2020

Choose a reason for hiding this comment

anntzer Nov 1, 2020 • edited Loading

Choose a reason for hiding this comment

tacaswell commented Oct 31, 2020

timhoffm commented Nov 1, 2020

anntzer commented Nov 1, 2020

timhoffm commented Nov 1, 2020

github-actions bot commented Jun 14, 2023

jklymak commented Jun 14, 2023

github-actions bot commented Aug 16, 2023

anntzer commented Aug 16, 2023

anntzer commented Apr 23, 2019 •

edited

Loading

anntzer commented Sep 19, 2019 •

edited

Loading

anntzer commented Sep 19, 2019 •

edited

Loading

anntzer Nov 1, 2020 •

edited

Loading