Repository navigation
[MNT]: Reconsider Seaborn style renaming #24256
Description
Summary
Version 3.6 of Matplotlib deprecates the seaborn style names, and renames them seaborn-v0_8. Renaming them causes technical debt to current users of these styles, and also creates technical debt in future as other styles may need to be renamed for consistency.
Proposed fix
I agree that each step of this decision starting from this PR was sensible, and yet, as an end user, I found the net effect of this change to be very user-unfriendly (I came across it when my Read the Docs builds started failing). As someone here commented, they like Matplotlib's ggplot style regardless of whether it maps onto the current version of ggplot. What happens if ggplot changes its default style? What about fivethirtyeight? Are all of these styles going to end up with awkwardly versioned names? I know I'll feel frustrated struggling to remember whether these styles are named seaborn0.8, seaborn-v08, seaborn_v0_8, etc. Since these styles exist purely for convenience (otherwise, you can just use Seaborn), making them significantly less convenient seems to defeat the purpose of including them.
While I agree it's not ideal to have styles named seaborn that don't (necessarily) match the current versions in Seaborn, I think the alternative of renaming them to a specific version (a) causes extra work for (the vast majority of) users who just want the styles to work, (b) is confusing since listing one version implies that other versions will exist, (c) creates technical debt by setting a precedent for needing to update other plotting styles. Thus, I would argue that the best among the set of not-great options is just to leave these styles -- and their names -- as-is.
Activity
mwaskom commented on Oct 23, 2022
It feels like the natural direction of this argument is that matplotlib should just not ship built-in styles named after other IP, versioned or not.
cliffckerr commented on Oct 23, 2022
@mwaskom I agree that avoiding naming styles after other IP would've been the best choice originally (especially if you and other authors of those styles weren't consulted), though given that it's already happened, I think the decision is less obvious. Apologies if this was already discussed, but perhaps another (imperfect) option would be to append like to the names: seabornlike, ggplotlike, etc. This would still cause some technical debt to existing users of these styles, but at least it would avoid the need to remember styles with names like seaborn_v0_8-whitegrid and fivethirtyeight_v2022-Oct-23_10_27_43 :)
mwaskom commented on Oct 23, 2022
I don't think you really need to worry about that because the "fivethirtyeight" (and "ggplot") styles are closer to an emulation or homage than an attempt at direct replications. (The ggplot style is pretty far off what what default ggplot looks like; I'm less familiar with fivethirtyeight but I think their plots are typically more stylized than you could achieve just through rcParams).
Whereas seaborn defines its styles in terms of matplotlib rcParams so matplotlib could, in theory, achieve exactly the same results (and it is confusing when it doesn't).
Also, I believe that matplotlib plans to deprecate the seaborn style and to keep the versioned name only for backwards compatibility, not to introduce the concept of "versioned styles" on an ongoing basis.
story645 commented on Oct 23, 2022
Eh, we've discussed this, in part as a way to more easily facilitate deprecation of styles and as a path for creating new styles that could then be more easily updated. The discussion kinda started at #23598 (comment)
mwaskom commented on Oct 23, 2022
I think the discussion in that issue comment is a little bit different — I take that as adopting an internal versioning system for matplotlib themes, not instituting a rule that themes based on external libraries will track those libraries versions.
tacaswell commented on Oct 23, 2022
I it unlikely we are going to change course on the 'seaborn' style. We can not both a) keep our styles consistent over time (because the visual output if Matpoltlib is part of our API) b) track changes in actual seaborn's styling. Given that tension we decided to remove the name, but keep seaborn-v0_8* around to give a back-compatibility path if needed and to be clear that it is the style that matches seaborn v0.8.
@mwaskom is correct, the discussion going about how to do "versioned styles" about being able to update home-grown styles (like "dark") rather than to accommodate following external IP.
mwaskom commented on Oct 23, 2022
FWIW the seaborn situation is kind of a weird edge case because the main reason its style definitions changed was to track matplotlib's changes (in v2.0). But that ship has sailed.
jklymak commented on Oct 24, 2022
I'm going to close as won't-fix; @cliffckerr, sorry this is a hassle, but this was pretty thoroughly discussed by the dev team when the decision was made so I don't think there is much chance we will directly revert this.
Note that we will soon likely have a way to use styles from installed, but not necessarily imported packages. Perhaps seaborn will make a style file available that tracks their internal styles.
cliffckerr commented on Oct 24, 2022
Thanks @jklymak -- I understand there are a lot of competing priorities here and there's no way to satisfy everyone!