I am a bit concerned about the validator having side effects, but overall 👍

The only way to resolve the list to a single value is to import pyplot and implicitly triggeringpyplot on access to rcParams seems much worse than the violation of type stability onget_backend andrcParams['backend'].

Well, you can comment on#11509 re: validator side effects :)

@jklymak The only place Matplotlib has any opinions about what backend you are using is in pyplot (and is the only place this value matters). When you import.pyplot we look at the value inrcparams['backend'] and then import the machinery from the correct backend module and hook it up soplt.figure() does "the right thing". This is why you currently have to calluse before you importpyplot for it to matter. I suspect the a few phases down the line of this will be to keep deferring this as much as possible so that you are not locked in until you actually create a figure (@WeatherGod wants this), but getting there in small steps will be easier to review.

@timhoffm Those are fair points, but the backend is very different than the other settings. It makes sense to have many figures with different sizes, however while (theoretically) it is it technically possible to have more than one GUI framework running in the same process (see#4779 for lots of details on the event loop integration problem) so switching the backend is necessarily a global change (one of the steps is to close all open figures!). If we don't let the backend validator have side effects then we can get our selves to a state where the actually backend being used (if you ask the canvas object of a live figure what it's module is), the result ofmpl.get_backend andrcParams are out of sync with each other.

I suspect the history of 'backend' being in rcparams was "we should be able to control the backend from a configuration file -> we already have a configuration file -> rcParams['backend'] is created" despite there being some pretty big semantic difference. 'backend' is not the only one in this boat, see

@tacaswell already answered most of the queries but here are a few more points.

@jklymak I suspect the a few phases down the line of this will be to keep deferring this as much as possible so that you are not locked in until you actually create a figure (@WeatherGod wants this).

AFAICT this is already the case with this PR.

@timhoffm Those are fair points, but the backend is very different than the other settings. It makes sense to have many figures with different sizes, however while (theoretically) it is it technically possible to have more than one GUI framework running in the same process (see#4779 for lots of details on the event loop integration problem) so switching the backend is necessarily a global change (one of the steps is to close all open figures!). If we don't let the backend validator have side effects then we can get our selves to a state where the actually backend being used (if you ask the canvas object of a live figure what it's module is), the result ofmpl.get_backend andrcParams are out of sync with each other.

Indeed, keepingmpl.get_backend andrcParams["backend"] and the actual backend in sync is the motivation here. However

1. I don't think we actually need to close the windows anymore in switch_backend, because there's actually no problem switching from, say, qt5agg to qt5cairo, and actually forbidden switches (from one interactive toolkit to another) will fail earlier (by the explicit check). (Of course, instead of changing the behavior of switch_backend, we can move the logic somewhere else and make switch_backend call it, yada yada.)

2. I agree that the "assign a list to rcParams["backend"]" behavior is quite weird.

• At least we should make it always immediately resolve the backend: there's no issue with importing pyplot immediately anymore, because it doesn't prevent backend switching. This way, reading from rcParams["backend"] will always return a single backend.

• The main reason this was added, though, was to make it possible for matplotlib to ship a default rcfile with the contents (e.g.):

backend: macosx, qt5agg, qt4agg, ...

which will try each backend until one can set up (currently, this selection of the default backend is done at build time, which is completely pointless as the toolkits available on the user's machine can be completely different (cf the patching of the default matplotlibrc by many downstream redistributors)). However, this is just a limitation due to the fact that matplotlibrcs are not actual Python files (cf MEP32); if we had python-syntax matplotlibrc, we could just do

for backend in ["macosx", "qt5agg", "qt4agg", ...]:    try:        use(backend); break    except ImportError:        continue

which is slighly verbose but the logic is easy enough to understand.

In the mean time, another solution (instead of supporting the assignment of lists, which I agree is a bit ugly) would be to support setting rcParams["backend"] to a special value (e.g. "auto" if we want to make it public, or a private singleton object (my preference)), to trigger this automatic resolution.

Maybe I've used too much words to state my intention 😄

IMO the sane API for backends would be this:

1. There should only bercParams['default_backend']. This defines the backend(s) pyplot should try when it needs a backend. This may be a list.
2. There should be functionsget_backend() andset_backend(name) to query and set the active backend.

I know, we're not there with the existing API, but in case we agree that my proposal is a desireable target state, we can implement a suitable migration strategy.

marking as WIP because I think#11600 is the canonical version of this...

Let's just close this as the other API is clearly better (regardless of the debate of whether to make assignment to rcParams["backend"] change the backend, allowing assignment of a list is too weird).