PR Summary

The current implementation ofRcParams inherits bothMutableMapping anddict. Inheriting fromdict has a few problems IMO,

• Any changes indict get propagated toRcParams directly. (Can't import matplotlib #12601)
• Subclassingdict meansRcParams can be modified usingdict.__*__ methods. As a configuration class for matplotlib, I think all updates toRcParams 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 fromRcParams which would affect the working of the library.
• It should not be possible to useRcParams as a store for keys other than the configuration keys with validators.

Proposed Implementation:

• Remove thedict inheritance and just inheritMutableMapping 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),}

Wheredefault_<namespace>_values are the default values of theRcParams 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 extraRcParamsDefault object as these defaults will be present in the base default values of the ChainMaps.
• Contexts can be implemented more elegantly usingnew_child andparents in ChainMaps as compared to the the current method of creating and deletingRcParams objects.

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

would output

within contextChainMap({'key1': 123}, {}, {'key1': 'abc', 'key2': 'xyz'})after contextChainMap({}, {'key1': 'abc', 'key2': 'xyz'})

• Complete control over the interface since it is defined entirely by the library.
• Also satisfies other niceties outlined inRequirements 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 forMutableMapping is slightly unruly to implement. (Though, I would argue that it should not work onRcParams 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 thematplotlib namespace to theRcParams class instead, clearing up the namespace a little bit. (#2052)

Performance Impacts

Introducing this structure instead of the entirercParams 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 formpl.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 thedict inheritance from theRcParams class and reimplemented its internals using ChainMaps. The interface is still compatible withMutableMapping interface. Using ChainMaps allows namespace access too, for examplercParams['text'] will return all the properties undertext.*. I also like the way it allows context management usingnew_child() andparents. 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 likebackend todefault.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 addingdefault. to the settings that did not fall under any "category".

I did not implement thefind_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 (andpytest passes)
• Documentation is sphinx and numpydoc compliant (the docs shouldbuild 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 indoc/users/next_whats_new/
• API changes are marked with a.. versionchanged:: directive in the docstring and documented indoc/api/next_api_changes/
• Release notes conform with instructions innext_whats_new/README.rst ornext_api_changes/README.rst