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 thatonly 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 isway 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 withsetdefault style filtering (please set this keyonly 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 ofhow we fabricate the singleton configuration.

[edited]