Is this block just a big copy/paste? (so we don't have to bother reviewing the code if it is)

It is,except for the fact that the FigureManager attribute now defaults to FigureManagerBase.

Can you add a comment explaining this bit of magic? I get that it returns a base _Backend class, but am not quite sure whatvars(backend_mod) does.

vars(obj) returns the attributes of obj as a dict. In the case of a module, that's basically the module's contents.

So effectively it's as if I'm running all of the module's code (of course, not a second time) from within aclass Backend(_Backend): ... context, and refetching attributes from that class. The point being that the base _Backend class can provide default implementations of backend_version, show, draw_if_interactive through inheritance rather than pylab_setup having to do it manually. Will add a comment to that effect, but does that sound good?

yeah, not objecting to the magic at all, but I think a short comment to help those of us with lesser python skills know whats going on would help make sure the code stays maintained...

added comment.

So we create the class, use the inheritance to fill in the missing functions and then return class level functions (which 'forget' they were part of the class)?

That is quite clever.

To check, if a backend is already using@_Backend.export then there should be nothing extra we need to provide?

Indeed, backends that were using@_Backend.export don't really need that anymore (the contents of the local _Backend class could just be dumped at the module level (or alternatively they could just do without the temporary creation of a new Backend class))... except for one thing: the _Backend class still allows inheritance between backends, so that e.g. _BackendQt5Agg can inherit from _BackendQt5.

There is a very subtle API change in here if people are looking at__name__,__module__, or__file__ of these classes. I am not sure if that is worth an API change note or not.

I added an API note. The real intent here is the following:

I think the "correct" way to refer to a backend's FigureCanvas, FigureManager, etc. class is under the unsuffixed names (FigureCanvas instead of FigureCanvasPS, etc.) The reason is that 1) these unsuffixed names need to be defined anyways for the backend machinery to pick them up, and 2) some of these classes (FigureManager, Toolbar, though not FigureCanvas of course) can be shared between multiple backends (for example, the xxxcairo backends and mplcairo just reuses the FigureManager classes for each of the GUI toolkits).

So sure, I can define (e.g.) FigureManagerQt5 and FigureManagerQt5Agg and FigureManagerQt5Cairo and FigureManagerMplCairoQt to all be aliases (or trivial subclasses) of one another, but that's just muddying the picture IMO; promoting the use of the same FigureManager name everywhere seems clearer.