No way to set default numeric color palette

[ofir-reich]

There is no way to set the default numeric colormap, it is always 'cubehelix'.

You can set the default categorical colormap using e.g. sns.set_palette(palette='Set1').

However, the default numeric color palette seems to always stay 'cubehelix'. Here is the relevant line in numeric_mapping: https://github.com/mwaskom/seaborn/blob/445a54aa46e279406949e0a3c2eed88d6cf80223/seaborn/_core.py#L235

Contrast this with the line in categorical_mapping, which uses the set default palette: https://github.com/mwaskom/seaborn/blob/445a54aa46e279406949e0a3c2eed88d6cf80223/seaborn/_core.py#L200

A suggested fix is to add a function sns.set_numeric_palette or an argument in sns.set_palette or something like that, and then in numeric_mapping have a call to something like numeric_color_palette() which reads the currently set default numeric color palette.

Thanks for all the great work!

[mwaskom]

The challenge is that seaborn's global state manipulation uses only the rcParams that matplotlib offers. This is by design, both for defining the scope of seaborn's internals (dealing with all the global state stuff is complicated and not something I'm too interested in dealing with), and so that people coming from matplotlib can have reasonable expectations about what is configurable.

Back when matplotlib was debating the changes to their default visual parameters for 2.0 I pushed on them to distinguish image colormaps and mappable artist colormaps in the rcParams, which would have allowed this. For an image/heatmap, you generally want a lot of luminance contrast, but for lines/scatter points, etc. too much contrast will mean the lightest elements become invisible. But they were against the idea for reasons that I continue to not understand.

It could be possible to try again for matplotlib 4.0. I've also heard them mention the idea of adding a way for downstream packages to define their own custom rcParams. But for the time being, this request is more complicated than it otherwise seems because it would require a significant change to one of the principles of how seaborn works.

So I am not against the idea directly (sure, it's annoying to have to pass a parameter to each plot to use something more custom), but not sure it's important enough to merit implementing a whole seaborn-specific global state system.