Requirements for a new configuration management class

[tacaswell]

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 setdefault style 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]

[jklymak]

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]

I see @timhoffm had this idea a while ago: https://github.com/matplotlib/matplotlib/pull/12577 [edit: well, a related idea]

[timhoffm]

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

provide a bug-for-bug compatible read/write accessor that mimics the current rcParams.

can be realized either by making the new config class API compatible with rcParams. Alternatively, we can have a new mpl.config with whatever API we like and turn rcParams into a proxy that only translates to mpl.config and 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. rcParams will only stay for backward compatibility.

[timhoffm]

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]

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]

https://docs.python.org/3/library/collections.html

Stdlib ChainMap is almost exactly that idea