MNT: Move "backend" from a regular rcParams dict entry to a class attribute by timhoffm · Pull Request #31792 · matplotlib/matplotlib

…ribute

Working towards matplotlib#31791.

> rcParams should be only configuration, not state; i.e. wrt. backend, it
> can hold the desired backend and backend priorities, but it should not
> hold the currently active backend or trigger backend selection as a
> side-effect. The latter causes a lot of complexity in rcParams.

This PR is the first step in the migration strategy outlined there:

> Make the backend a RcParams class attribute and do not hold
> "backend" as a regular dict entry. There can only be one backend,
> so putting that value in a class attribute `RcParams._backend` makes
> sense. This already reduces the complexity as we don't need special
> handling to sync/copy the value when rcParams are bulk-replaced
> (loading from file or rc_context). Instead add special logic to keep
> behavioral backward compatibility with the dict API
> (`rcParams["backend"]` / `rcParams._get("backend")` /
> `"rcParams._set("backend", val)`).

Note on API compatibility: This PR limits itself to the known typical
dict-API usages in the context of backend handling. I've refrained from
trying to fully replicate dict behavior of a "virtual" "backend" parameter,
i.e. `len(rcParams)` / `rcParams.keys()` / `rcParams.values()` /
`rcParams.items()` do not contain "backend" anymore. I would be willing to
accept this level of API breakage. If deemed critical, we could add
compatibility shims for that too.