Seems like there is strong support in the community for this feature request, let's prioritize this for the following release. cc @connortann @dsgibbons

Thank you, @thatlittleboy , I would love to help if possible on implementing some features, but I don't understand the code structure at all (i haven't digged up much though). If i can help with something, just let me know. Discord: eZWALT

@CloseChoice , we have two PRs with possible implementations for this feature. I think it's quite an important design choice which direction we set, so I wanted to discuss some ideas with you before deciding how to proceed.

Design considerations

Some considerations that come to mind are:

• Separation of config from code (e.g. perhaps using static config files)
• Compatibility with the wider ecosystem (e.g. matplotib)
• Simplicity
• Customisability

In terms of functionality, we might want to be able to set a global "style" that is persistent and will affect every plot they create.

Option 1: Config options for each plot

I think a config dataclass makes sense for a single plot, as in #3377. However, I'm a bit concerned that it could rather messy if we extend this to handle other plots.

It becomes a bit tricky if we want to re-use certain parameters between plots, as it looks like each plot might have its own set of config options. Moreover, there is a really large number of possible style options, from fonts, text sizes, tick sizes, and so on. Some options would probably be shared between plots, whereas others are plot-specific.

If our config dataclass accounted for every customisable option, they might become quite large and bloated. Another difficulty is that it pollutes the signature of the plotting functions, as this config object has to be passed to each plot.

Option 2: matplotlib's rcParams

What do you think about using the matplotlib rcParams (runtime params) system? This is the mechanism that seaborn uses, and I think it works well. It allows us to separate the style configuration from the plotting, and the plotting functions just pick up whatever style is currently defined.

From the matplotlib docs:

You can dynamically change the default rc (runtime configuration) settings in a python script or interactively from the python shell. All rc settings are stored in a dictionary-like variable called matplotlib.rcParams, which is global to the matplotlib package.

Seaborn offers a high-level API that uses this system, e.g. sns.set_style. Seaborn has high-level functions which internally change the matplotlib rcParams object:

The style parameters control properties like the color of the background and whether a grid is enabled by default. This is accomplished using the matplotlib rcParams system.

To my mind, the advantage of using this kind of config system would be:

• Consistency with wider ecosystem
• Separation of concerns: "setting style options" vs "making plots"
• Ability to override the global defaults, e.g. with a rcParams file
• Ability to share config settings between different plots (e.g. primary color, secondary color...)

I note that matplotlib does not allow us to define custom parameters, as far as I can see. So, we could either to make use of existing settings, or perhaps create our own rcParams singleton.

As inspiration, I note that another plotting library ArviZ implemented a rcParams system that follows the behaviour of matplotlib. We could perhaps take that as inspiration:

arviz-devs/arviz#734

@connortann
I can see your point and also see the downsides of the dataclass solution. Here a breakdown of my thoughts:

Option 1: Config options for each plot

• this allows us and the user to specifically document what can be changed by which parameter (in contrast to rcParams. E.g. there are exactly four parameters that we allow to change in the waterfall plots (of course this can be extended in the future).
• this option would give us a transparent overview over all styling options and then we can generalize styling options from there. Of course this might involve breaking changes which should be done with care but it allows us incrementally to use the styling feature.
• I do not really see the issue (not considering my PR here) that this is polluting the signature. We can basically just allow the dataset class + one other option which should lead to highly bloated signatures (or avoid type hints here altogether).

Option 2: some sort of rcParams

• since it is not obvious which plot supports rcParams settings it is hard to do this incrementally without confusing users. IMO we would need a major effort to implement this in most/all of our plots at once
• when I am working with rcParams I am often confused which setting to use. So the lack of transparency is an issue IMO.
• consistency with the ecosystem is an absolute plus
• reusability is IMO in most cases a plus but it is also shared state between plots which as you pointed out might be hard to get right (which style settings should be applied for all plots, which shouldn't).

Why don't we go for a dataset class-ish solution where we initialize the dataclass values with settings from rcParams?
How would that look like? The style (or rc) argument in the plot is optional and defaults to None if it is not set the dataclass is instantiated with the matplotlib rcParam values. Then we can do things incrementally and also take into account global styling. Of course this would mean one data class for each plot.

Related to the rcParams discussion: #1430

I found quite a few issues from the past few years relating to the plotting API. I created a label "visualisation" to track these, and a "meta-issue" to discuss the over-arching effort: #3411

One thing that strikes me is that there is a desire not just to be able to customise elements such as colours, but also to have consistency between plots in things such as fonts, tick params & spines. I also think having separation of concerns is going to be really important, as I can see this getting very complex very quickly.

So, how about a hybrid approach of the options above: custom style options, implemented as a global setting or context manager?

Inspired by seaborn's example, the API could be like this:

# Global settings
shap.plots.set_style(...)
shap.plots.bar(shap_values)
shap.plots.beeswarm(shap_values)

# Or as a context manager
with shap.plots.set_style(...):
    shap.plots.bar(shap_values)

@connortann This looks like a good approach to me. I think we might need a prototype for this and then decide on how to roll this out for other plots.

related discussion #2566
related issues: #2767