underscore to not make this a publically accessible global

I actually don't think we should allow del'ing items from the rcParams as that has no sense. It may not have been worth it to prevent that with the old implementation, but now it's just a matter of replacing the implementation by a raise TypeError.

Yes, you're right. The current code prevents it, because we did not reimplement theMutableMapping.__delitem__. Before we were just inheriting fromdict, so del'ing should have been possible. InheritingMutableMapping was introduced within a large commit#7549. I dare assuming that both behaviors were incidental and nobody really thought about it.

I'm extending the RcParams in my private code to be able to style and style-context some of my plot elements in specialized plots. While I'm currently not del'ing anything I could imagine that there's a use-case for that. Maybe we should prevent del'ing only for values that are in the defaults.

But as a first step it's ok to stay as restrictive as we currently are.

Talking about custom extensions to rcParams (none of which are really using the public API I guess), I realized that this PR would breakhttps://github.com/anntzer/mplcairo#antialiasing where I usedict.__setitem__ to bypass the validation code on input (to set lines.antialiased to one of the many cairo antialiasing modes, whereas the validator just accepts True/False).
I guess that's related to your point in#12577 (comment)...

I was hoping nobody would mess with the implementation details ofRcParams in such a way except our own code. Ok, then we have to take it a step slower, define an official API for that and only later migrate to theMutableMapping.

By the way, What was your reason for introducing the multiple inheritance in the first place? IMO deriving fromdict is not good but still far better than deriving fromdict andMutableMapping.

I was hoping nobody would mess with the implementation details of RcParams in such a way except our own code. Ok, then we have to take it a step slower, define an official API for that and only later migrate to the MutableMapping.

To be fully consistent with my own general approach wrt backcompat ("we should consider whether it'll actually matter to enough people that we reject a backcompat break"): I'm not going to throw a fit if the API changes here, and having a "more official" way to bypass the validator would be better anyways.

By the way, What was your reason for introducing the multiple inheritance in the first place? IMO deriving from dict is not good but still far better than deriving from dict and MutableMapping.

When I wrote it, it seemed to be a good way to provide update() cheaply.
In fact, looking at it again:

• I guess you can still make it just inherit fromdict, keeping most of the old code, and then doupdate = MutableMapping.update (thus easily stealing the implementation from MutableMapping without pulling in the whole multiple inheritance problem, and not breaking my approach in mplcairo :p);
• I think the fact that len(rcParams) == 0, i.e. that callsMutableMapping.__len__, is a CPython bug:https://bugs.python.org/issue35063

LGTM