PR Summary

The current implementation of RcParams inherits both MutableMapping and dict. Inheriting from dict has a few problems IMO,

• Any changes in dict get propagated to RcParams directly. (Can't import matplotlib #12601)
• Subclassing dict means RcParams can be modified using dict.__*__ methods. As a configuration class for matplotlib, I think all updates to RcParams should be possible only using methods defined by the class. (Data access API for rcParams #24730, RcParams should not inherit from dict #12577 )
• As it is basically a dictionary, keys can be deleted from RcParams which would affect the working of the library.
• It should not be possible to use RcParams as a store for keys other than the configuration keys with validators.

Proposed Implementation:

• Remove the dict inheritance and just inherit MutableMapping to main that interface.
• Introduce namespaces by restructuring the parameters ingested as a dictionary of ChainMaps.
  For example:

namespace_maps = {
    "backends": ChainMap({}, default_backends_values),
    "lines": ChainMap({}, default_lines_values),
    "fonts": ChainMap({}, default_fonts_values),
}

Where default_<namespace>_values are the default values of the RcParams under that namespace. For example.

default_backends_values = {"webagg.port": 8080, "webagg.address": "127.0.0.1", ...}

Advantages:

• Allows concrete grouping of keys, not just visually by key as is the case right now (dotted keys).
• Contextually related keys can be accessed easily using namespaces.
• No need to maintain an extra RcParamsDefault object as these defaults will be present in the base default values of the ChainMaps.
• Contexts can be implemented more elegantly using new_child and parents in ChainMaps as compared to the the current method of creating and deleting RcParams objects.

with rc_context(rc={"backends.key1": 123}):
    print("\nwithin context")
    print(rcParams['backends'])

print("\nafter context")
print(rcParams['backends'])

would output

within context
ChainMap({'key1': 123}, {}, {'key1': 'abc', 'key2': 'xyz'})

after context
ChainMap({}, {'key1': 'abc', 'key2': 'xyz'})

• Complete control over the interface since it is defined entirely by the library.
• Also satisfies other niceties outlined in Requirements for a new configuration management class #24585 like being able to jump easily to and from user-defined value to baseline value.

Disadvantages:

• popitem() method for MutableMapping is slightly unruly to implement. (Though, I would argue that it should not work on RcParams in any case). Also, relevant discussion here (RcParams should not inherit from dict #12577 (comment))
• Tinkering with a long-existing part of the code?

Doing this will also allow us to move some extra functions that exist in the matplotlib namespace to the RcParams class instead, clearing up the namespace a little bit. (#2052)

Performance Impacts

Introducing this structure instead of the entire rcParams being a dictionary makes it a little slower. The timings for a get operation on both the methods were measured using %timeit for 1,000,000 loops each.

Current Implementation (dict):

In [3]: %timeit -n1000000 mpl.rcParams.get("animation.convert_args", [])
216 ns ± 16.3 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

Proposed Implementation (ChainMaps):

In [12]: %timeit -n1000000 mpl.rcParams.get("animation.convert_args", [])
918 ns ± 1.03 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

For completion, while disabled right now, the timing for mpl.rcParams["animation"]["convert_args"] is also measured

In [15]: %timeit -n1000000 mpl.rcParams["animation"]["convert_args"]
467 ns ± 15 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

Older description

I removed the dict inheritance from the RcParams class and reimplemented its internals using ChainMaps. The interface is still compatible with MutableMapping interface. Using ChainMaps allows namespace access too, for example rcParams['text'] will return all the properties under text.*. I also like the way it allows context management using new_child() and parents. The main goal of the PR is just to see what a different implementation might look like per #24585 and have some more discussion.

This implementation can be made efficient. I also have changed a few things like backend to default.backend which is something we might not want in the actual implementation but I have changed here because the focus was on having an implementation and not worrying way too much about changes. It's mainly adding default. to the settings that did not fall under any "category".

I did not implement the find_all method initially because from a quick github search, it isn't used anywhere, but it can now be implemented fairly easily by searching on the keys. The __repr__ and __str__ differ from the current implementation as they have a very simple implementation right now.

PR Checklist

Documentation and Tests

• Has pytest style unit tests (and pytest passes)
• Documentation is sphinx and numpydoc compliant (the docs should build without error).
• New plotting related features are documented with examples.

Release Notes

• New features are marked with a .. versionadded:: directive in the docstring and documented in doc/users/next_whats_new/
• API changes are marked with a .. versionchanged:: directive in the docstring and documented in doc/api/next_api_changes/
• Release notes conform with instructions in next_whats_new/README.rst or next_api_changes/README.rst