Thematplotlib.use API has been there from 2004 (goes all the way back toe34a333) and it is in a lot of code / documentation / examples. I am not convinced that the slight improvement in the verbiage is worth disrupting a considerable fraction of our users. While if we were going to be starting from a clean slate I agreeset_backend is a better name, I am 👎 on deprecatinguse.

I am 50/50 on addingset_backend as an alias foruse, it is a better more guessable name, but now we have 2 versions of the call...

Similarly, storing the current backend inrcParams has been there as long, ex the current implementation ofget_backend is:

I think I am on board with pushing people toget_backend instead ofrcParams['backend'], but that is going to need a long (multi-year) deprecation cycle.

I am 👍 on adding'default_backends' as a parameter, but (as discussed on the call today) we may want to move things like backend, interactive, etc out of rcParams all together so we should have a plan for that before we put it in.

The changes are rather independent and could be introduced incrementally, if we are not sure about some of them:

1. Enabling backend switching itself does not need any new API. I can simply allowmatplotlib.use() when there already is a backend.
2. Introducingset_backend() is optional and can be done anytime as this is just an alias ofmatplotlib.use().
3. Deprecatingmatplotlib.use() after introducingset_backend() is optional. I accept the argument that this would be disrupting existing users. One alternative approach would be aPendingDeprecation. This would tell new users, that they sould useset_backend() but could keepmatplotlib.use() for a long time without nagging existing users with a deprecation warning.
   But it's also a fair decision to just keepmatplotlib.use(). I just would not recommend to have bothset_backend() andmatplotlib.use() as pure aliases. There should be one recommended way, even if we allow both to exist.
4. Deprecating queryingrcParams['backend'] to get the current backend in favor ofget_backend() is optional. Could also start with a PendingDeprecation.
5. Introducing the support for a list of default backends is optional. I just recommend not to inject that functionality intorcParams['backend'], but first establish a distinct entity for holding the defaults (as opposed to the current value) -rcParams['default_backends'] would be one solution for this.

A reasonable minimal start for 3.0 could be just to do 1. (and maybe 4.) - acknowledging that the original PRs#11581 and#11600 are tagged3.0 andrelease-critical. The other points seem to be more controversial and there is no need to rush it.

@timhoffm I agree with your suggestions above. OTOH for now we want to get backend switching in, and the existing rcParam stuffing, while suboptimal, is the existing API. So for 3.0 I think we decided to move along w/@anntzer PR (plus or minus any review changes) and then we can re-open the deprecation/API refinement for 3.1 (due December-ish).

Superseeded by#11600