René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Requirements for a new configuration management class","articleBody":"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.\r\n\r\nThis 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\r\nno way of telling if a value was intentionally set to a value that just happened to be the default value or not.\r\n\r\nI would propose the following set of requirements:\r\n\r\n - 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\r\n   to really deprecate\r\n - 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\r\n - a way to tell the object that its current state should be considered the new baseline\r\n - a way to move a key back to the baseline value\r\n - provide a way to access (namespaced) sub-sets of the configuration\r\n - validation on the keys (must be in expected list) and values (must be of expected type)\r\n - bulk update / restore of keys with `setdefault` style filtering (please set this key _only_ if it has never been updated)\r\n - ability to lock keys (both \"soft lock\" that can be unlocked and \"hard-locked\" that can not?)\r\n\r\nOther things we should consider:\r\n - move to `__getattr__` rather than `__getitem__`\r\n   - pro: dot access is a bit nicer\r\n   - con: conflicts between the key namespace and the method namespace\r\n - runtime extension of known keys\r\n   - pro: if we start pushing to more sub-libraries it would be good to have a unified config management scheme\r\n   - con: namespace chaos\r\n\r\n I want to keep this discussion independent of _how_ we fabricate the singleton configuration.\r\n\r\n\r\n[edited]","author":{"url":"https://github.com/tacaswell","@type":"Person","name":"tacaswell"},"datePublished":"2022-12-02T21:06:29.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":7},"url":"https://github.com/24585/matplotlib/issues/24585"}