First thought: Does this involve any costly setup logic? We are already quite slow in creating figures.
Answer: Apparently not. -> Ok.

Second thought: IsFigureCanvasBase the right class? It's not used explicitly except in some tests. Should we maybe have

class PrintableFigureCanvas(FigureCanvasBase):    pass

just for semantic reasons?
Maybe not. Not sure myself.

Third thought: Do we now get more strange behavior or error message when we try things that would before fail due to the missing canvas?

1. I strongly doubt it matters performance-wise (the base class__init__ just sets a bunch of attributes), and I guess you actually did time it :)
2. Seems overkill to me.
3. Figure().canvas.draw() now does nothing instead of raising an AttributeError ("None has no attribute "draw"), but that's sort of the point of the PR... (I guess youcould split out draw() in its own subclass of FigureCanvasBase but... let's not.)
   It shouldn't be too hard to revert this if we merge it early in the 3.1 cycle and it turns out to be problematic :)

and I guess you actually did time it :)

No just looked at the code 😄

2. Ok.

It shouldn't be too hard to revert this if we merge it early in the 3.1 cycle and it turns out to be problematic :)

Doesn't sound well thought through. I haven't either, but I'm hesitant to introduce a code change with an effect that we do not overlook.

Doesn't sound well thought through. I haven't either, but I'm hesitant to introduce a code change with an effect that we do not overlook.

I actually really think it's not going to cause any problems, but as usual things are tied up in so many knots in mpl that it's hard to know if we don't try.

This code was last touched inb0807ae which was primarily reverting#1125

The originalself.canvas = None and the logic of the canvas setting its self to the Figure came in in770d0a0

I suspect looking at why#1125 failed would be a good guide to if we are missing something here. From a very quick look, that PR defaulted to getting the current backend from pyplot (more-or-less) where as this is is going with the base class which has just enough logic to fall-back on save.

Another option is to makecanvas a property and defer creating a canvas until someone asks for it, but I am not sure it is worth the complexity / runtime cost.

Looking at#1457 (comment) it looks like#1125 failed because not all Canvas classes have the same constructor signature, but that's not a problem here.
I think#1457 (which was likewise rejected) failed because it also tried to construct a FigureManager by default (even if it doesn't use it, it's still present) to workaround that signature variation.

In both cases I think using FigureCanvasBase avoids these problems.