displot instantly close upon display when using seaborn 0.11.2 with matplotlib 3.5.2

[kailizcatman]

I encountered a case of figure window closing instantly when trying to display a displot.

To reproduce, try the following with seaborn version 0.11.2 and matplotlib version 3.5.2

import seaborn
import matplotlib.pyplot as plt

sns.displot([0,0,1,1,2,3,3,1,0])
plt.show()

In seaborn version 0.11.2, a figure window will flash on the screen and instantly disappear, whereas in seaborn version 0.11.1, a histogram bar plot is displayed in a new window that persists until I closed it.

After some digging, I suspect that this is due to the handling of the backend entry of matplotlib.rcParams. rcParams["backend"] by default is initialized with a sentinel object matplotlib.rcsetup._auto_backend_sentinel. The first time someone tries to access rcParams["backend"] , matplotlib will call matplotlib.pyplot.switch_backend to swap in the actual backend object. The function matplotlib.pyplot.switch_backend, when called, will first close all currently open figures.

In seaborn version 0.11.2, displot will try to create a FacetGrid object in which to place the plot. In the constructor of FacetGrid, at line 408, it creates a Figure object within a context manager. As a result, the rcParams["backend"] gets reverted to the sentinel object upon exit from the with block. The created Figure would get automatically closed the next time the code tries to access rcParams["backend"].

[mwaskom]

Thanks for tracking this down and reporting! I'm not 100% sure I am following, but it does sound like this is something that should ultimately get fixed upstream in matplotlib? I think if they are really doing some "first time only" logic using a sentinel, it would make sense for rc_context not to reset that parameter upon exit. But probably a little tricky to define what the "right" behavior is here.

Am I understanding correctly that seaborn could work around the issue by adding something like

_ = mpl.rcParams["backend"]

prior to initializing the figure (and outside the with block)?

[kailizcatman]

I thinking the workaround of adding a mpl.rcParams["backend"] somewhere before the with block should work. Let me try reporting this to the matplotlib people.

[kailizcatman]

It seems that a matplotlib developer fixed this about a month ago matplotlib/matplotlib#23298

[mwaskom]

Great, thanks for finding the relevant matplotlib issue.

If there's a small (and side-effect-less) workaround that seaborn could implement for users on mpl<3.6, happy to add it.

[kailizcatman]

Let me comment on the issue to see what the matplotlib people thinks. My naive thinking is that any workaround for this issue is bound to have some side-effect (i.e. rcParams["backend"] become updated).

[kailizcatman]

The recommendation from matplotlib developers is to add something like the following.

import matplotlib
matplotlib.get_backend()
del matplotilb

In our case, we can probably do this just after importing matplotlib and dispense with the last del command. Judging by the source code of matplotlib.get_backend, this is essentially equivalent to just rcParams["backend"]. I am not sure whether it is absolutely necessary to include such a matplotlib version-specific workaround in seaborn. I am inclined to either wait to update matplotlib in my environment or do the simpler rcParams["backend"].

[kailizcatman]

A matplotlib developer asked whether the rc_context was necessary in that case. I don't know seaborn enough to say whether it can do without the rc_context or not. Would you mind commenting in the matplotlib issue?

[mwaskom]

I don't really understand that question. The context manager is being used for its exact purpose: to temporarily change rcParams in a way that is guaranteed to get cleaned up later. I don't see how using, e.g. try/finally while implementing the same logic (capture rcParams, change them, then revert them) would avoid the problem.

That said, there is a very narrow reason that the context manager is being used here: it is to prevent the autolayout rcParam from causing the plot to overlap the legend (because tight_layout for some reason cannot natively handle figure legends, and that need to be manually worked-around inside FacetGrid). Given that, it would be possible to be selective about what rcparams to update/revert in a manual try/finally construct. So maybe that's the better (if clumsier) workaround.

[mwaskom]

This is a relatively easy workaround so I think it's the right path forward. See #2925; would be great if you can test and verify that it works on your system.

[kailizcatman]

I tested the branch in #2925 in my environment with matplotlib 3.5.2. It worked as expected. Thank you for working on this.

There is probably a question of philosophy and intention when it comes to using rc_context. It seems that some matplotlib developers believe rcParams and related mechanisms should only be used by end users in a somewhat interactive context.