Repository navigation
On making the rc-validators function know the rcParam affected instance #11509
Description
The RcParams class is probably treated as a singleton (with rcParams as the sole instance) by nearly everyone. I now have two cases where I either need to rely on this assumption, or at least need to make a rc-validator function know the actual RcParam instance that is being modified (if RcParam is a singleton, then we of course know what instance is being modified -- there's only one instance!).
Case 1) is #9795 (backend-switching), where I propose that assigning to rcParams["backend"] also sets the backend (currently, this has no effect after pyplot is imported, but I believe having rcParams["backend"] and the actual backend go out of sync is particularly bad in a world where backend-switching becomes better supported). But of course, the actual backend in use is global state, so the backend switch (which is implemented in the rc-validator function) should only occur if the currently modified instance is mpl.rcParams.
Case 2) is #11231, where I propose replacing multiple rcParams (figure.subplot.{left,right,...}) by a single one (figure.subplot). During the deprecation period, changes to figure.subplot.{left,right,...} need to be propagated to figure.subplot in the same instance, and vice-versa.
Making rcParams a singleton (for most purposes) is not particularly difficult (override __new__, yada yada) but perhaps inelegant? Making the validators know the currently modified instance is not too hard either, as all validators currently take a single argument (and no optional argument), so we can just say e.g. "if a validator takes two arguments (this can easily be checked at the very beginning), pass the RcParams instance as first/second argument".
Thoughts?
(Milestoning as 3.0 as it would be nice to resolve this before #9795, but that's not strictly necessary either as we can just make/document the assumption too.)
Edit: dates.converter and dates.interval_multiples are also entries that now assume that there's just a single rcParams instance, as assigning to them (regardless of whether it's on the main instance or not) always updates the global state regarding date formatters.
Activity
efiring commented on Jul 3, 2018
What is the potential use case for rcParams not being a singleton? It seems quite deeply embedded in mpl's design that it is a repository of global information. What seems to me inelegant is having that information include the backend, because choice of backend is completely different from all or nearly all the other sorts of things in rcParams, which are matters of style.
anntzer commented on Jul 3, 2018
Actually, I just realized that right now rcParamsDefault is also an RcParams instance (so RcParams is indeed not a singleton) but rcParamsOrig is a dict instead. It could make sense to make both of them RcParams, or both of them dicts.
I am not convinced that RcParams was intended solely for styling purposes (for example the "interactive" key also lives there, and there's a few other non-style-related entries); rather, it's just that there are way more styling keys than other keys. And it's not as if moving the non-style-related global info to some other variable would really help(?)
jklymak commented on Feb 9, 2019
Feel free to re-milestone if you still want this discussed in the next couple weeks.
anntzer commented on Sep 9, 2021
Conclusion from dev call is to perhaps add an additional dictionary of side-effects to the main rcParams instance (if really needed), but otherwise try to make the validators side-effect free.