Surprising behaviour from plt.style.use('theme'), themes being not exclusive

[kraktus]

Thank you for your work on this cornerstone lib.

Bug summary

Not a bug, since documented, but still a surprising behavior from plt.style.use('theme') not resetting values to the default before applying the new ones. Apologies if an issue already exist, didn't find one.

This updates the rcParams with the settings from the style. rcParams not defined in the style are kept.

This is especially an issue when using jupyter notebook for example, where one's would cycle through themes before sticking to one they think look good, while it's a mix of multiple themes and dependent of the order in which they've tried it!

Code for reproduction

plt.style.use("seaborn-v0_8-dark")
plt.style.use("dark_background")
# ...

Actual outcome

Mix of both styles.

Expected outcome

equivalent to

plt.style.use("dark_background")
# ...

Additional information

From what I've seen plotting appearance falls under breaking change, but I don't know how strict this is enforced. I'd expect people willingly setting multiple themes at the same time to get a custom style chimera to be quite small.

[jklymak]

@kraktus I think that is one of the reasons we have a theme context manager:

with plt.style.use('seaborn-v0_8-dark'): 
   plot() # seaborn theme

plot() # old theme 

People want to compose themes quite often (apply some of one theme, some of another) so, back compatibility aside, I expect it is unlikely that we will revert to default every time style.use is called.

[timhoffm]

We are good

The behavior is documented correctly: https://matplotlib.org/stable/api/style_api.html#matplotlib.style.use

Can we be better?

The default will not change, but possible extensions are:

• adding a parameter to start from default or
• allow styles to specify whether they are incremental to the current state or whether they are based on default (or another style). This is likely better than the parameter because whether a style is incremental or not is basically a static design decision of that style. It should be rare that one wants the same style config incremental in one case and absolute in another.

[tacaswell]

When we brought is styles the ability to compose them like this was one of the explicit design goals. If a style wants to be against the default, then it should copy more of the default values into itself.

This is something that the chainmap work @chahak13 has going may help with. Currently we can only say "go back to default" and no way to say "please undue the last style application" (short of the context manager).