Repository navigation
Requirements for a new configuration management class #24585
Description
Starting to think about what it would like to replace rcParams. It has served us well, but reflect what you could do with Python ~20 years ago (looks like it started as just a plain dictionary and picked up validation in 2007). Given the changes to Python, our experiences working with the current rcparams, and an eye towards near-term explosion of the number of things we may want to parameterize after the NASA work, I think it is worth having a discussion about what a green-field implementation of a global configuration signleton class would look like.
This line of thinking is triggered by a question via private communications about how to use a style file that only applies to rcParams that have not already been updated. In principle, you could do this by looking at rcParamsDefault (or some other baseline), but you would still have
no way of telling if a value was intentionally set to a value that just happened to be the default value or not.
I would propose the following set of requirements:
- provide a bug-for-bug compatible read/write accessor that mimics the current rcParams. The current system is way to widely used to break and very likely too widely used
to really deprecate - track what values have been set and provide a way to ask if a given key has had its value changed away from the baseline
- a way to tell the object that its current state should be considered the new baseline
- a way to move a key back to the baseline value
- provide a way to access (namespaced) sub-sets of the configuration
- validation on the keys (must be in expected list) and values (must be of expected type)
- bulk update / restore of keys with
setdefaultstyle filtering (please set this key only if it has never been updated) - ability to lock keys (both "soft lock" that can be unlocked and "hard-locked" that can not?)
Other things we should consider:
- move to
__getattr__rather than__getitem__- pro: dot access is a bit nicer
- con: conflicts between the key namespace and the method namespace
- runtime extension of known keys
- pro: if we start pushing to more sub-libraries it would be good to have a unified config management scheme
- con: namespace chaos
I want to keep this discussion independent of how we fabricate the singleton configuration.
[edited]
Activity
jklymak commentedon Dec 3, 2022
If you are doing some redesign, can I suggest some thought into different types of rcParams and differentiating when they can be set? We use rcParams as both defaults for various style things, but also for configuration of pretty crucial things like the backend, or things like a default layout manager or unit converters. Having some way to differentiate those roles (or locking them out), and clarifying when things can be set (before startup, before figure creation, before artist creation, before the next draw) would be really helpful.
I personally use style sheets, but otherwise avoid setting anything in my matplotlibrc except the default backend because I don't find it is very portable.
tacaswell commentedon Dec 5, 2022
I see @timhoffm had this idea a while ago: #12577 [edit: well, a related idea]
timhoffm commentedon Dec 6, 2022
#12577 is only loosely related. The new config class will be much more different than what is proposed in #12577. However, we need #12577 to enable reasonable compatibility
can be realized either by making the new config class API compatible with rcParams. Alternatively, we can have a new
mpl.configwith whatever API we like and turnrcParamsinto a proxy that only translates tompl.configand does not hold any config state anymore. I assume either way will be hard if you plan to continue supporting unbound dict methods operating on these objects).BTW, the new object should be available as
mpl.config.rcParamswill only stay for backward compatibility.timhoffm commentedon Dec 6, 2022
I have some older thoughts on the "new configuration class" topic at https://gist.github.com/timhoffm/0a4d3d2b01115d77f930ceaadc4523ac. May need some consolidation, but should be helpful for some additional ideas.
chahak13 commentedon Mar 25, 2023
What if the config class has two containers (dicts?) - one for the default that is set (a la
rcParamsDefault) and the other that contains "user added" options? This way, the burden of checking whether a user updated a value or not lies only on the existence of the key in the second dictionary and not on the value of that particular key. This would also satisfy all the requirements mentioned in the first comment about the behaviour of the configuration class by checking keys in the two.ksunden commentedon Mar 25, 2023
https://docs.python.org/3/library/collections.html
Stdlib ChainMap is almost exactly that idea
github-actions commentedon May 18, 2026
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!