maybe_backend_module for more clarity?

Also if you understand, what this really does, an explanatory comment would be helpful. Seems sort of a hybrid namespace for the module + class thing.

Added a comment to clarify.
I would prefer not changing _backend_mod, because in fact it should really be public: there should be a way to get a hold on "the canvas class of the current pyplot backend" without instantiating one. Right now if you look at e.g. the embedding_in_qt_sgskip.py example, you have something like

ifis_pyqt5():frommatplotlib.backends.backend_qt5aggimport (FigureCanvas,NavigationToolbar2QTasNavigationToolbar)else:frommatplotlib.backends.backend_qt4aggimport (FigureCanvas,NavigationToolbar2QTasNavigationToolbar)

and that won't even give you a qt5cairo/mplcairo.qt canvas even if your matplotlibrc is configured to do so; better would be something like

frommatplotlib.pyplotimportbackend_mod# name up to bikesheddingFigureCanvas=backend_mod.FigureCanvas

Anyways, this can be a discussion for another PR.

The motivation here is to slowly move to using the_Backend sub-classes rather than the modules as the namespace?

It seems simpler to do_backend_mod = improtlib.import_module(...)?

If you are in the mode of embedding, you sholud be directly picking the backend, not relying on pyplot's settings. While it would be solve your mplcairo vs qt5agg vs qt5cairo problem, it would go very badly if the end-user was set up to use wxagg.

Yes, I would ultimately like to make _Backend public, because there is really an inheritance-like relationship e.g. qt5agg inherits from qt5 + agg, before the introduction of _Backend this was implemented manually with a lot of redundant code whereas I would argue (well, I wrote _Backend so I'm perhaps biased here...) that things are now simpler by actually using real class inheritance.

_backend_mod = importlib.import_module(...) would not fill up missing methods in third-party backend modules (the pre-_Backend code did fill them), that's what inheritance does for you.

Re embedding: I can always start by creating a QApplication() early to prevent the other backends from being loaded (at worst I'll error out more or less cleanly). One motivation is that I want my GUIs to use mplcairo(.qt) when I can (because, well, I think mplcairo is awesome :-) but again I'm a bit biased...) but there's typically no need to actually have a dependency on mplcairo and I'm happy to fall back to qt5agg if that's all there is.

In any case, this PR is fairly unrelated.

Having backends as classes instead of modules makes sense to me.

Having backends as classes instead of modules makes sense to me.

Do we need theglobal here and in then next 2 functions?

I thought yes to placate flake8 similarly to theglobal _show in the old show() (see#10689), but apparently pyflakes got smarter since then, so removing them.