Notionally 👍 one slight behavior question.

Adding a the new parameter which is sometimes Nonefirst is a bit odd to me, but I see the argument for that as it is consulted first.

backend has priority over fmt, so that's why I put them in this order (also, it's private API anyways).

I'm a bit hesitant. A backend parameter insavefig() is a big API promise. I really don't claim to understand the whole backend machinery, but, setting the backend only for thesavefig() call feels too easy given that we've been jumping a lot of hoops to delay backend selection. Is this really a fully working solution that can live up to the API promised?

• Does nothing we do in any plotting command (now or in the future) depend on the backend? Otherwise just setting the backend insavefig() is not equivalent to setting the backend earlier, and that would be quite surprising.
• Following a similar logic, can we then equally doplt.show(backend='QtAgg')?
• Would a context manager for backends be a reasonable alternative.
• Do we need checks that the format/extension and the backend are compatible?

re@timhoffm:

Does nothing we do in any plotting command (now or in the future) depend on the backend? Otherwise just setting the backend in savefig() is not equivalent to setting the backend earlier, and that would be quite surprising.

Ibelieve not (the backend-dependent logic is in draw(), which is only called by savefig()).

Following a similar logic, can we then equally do plt.show(backend='QtAgg')?

Backend switching is subject to the same rules as use() (i.e. you cannot switch to an interactive backend requiring a GUI event loop once another GUI event loop is running). But switching to a noninteractive backend is fine (and the intended use case) -- note that wealready implicitly do so for printing to pdf/ps/svg; this kwarg only makes it explicit and allows you to switch to backend_pgf rather than backend_pdf when printing to pdf.

Would a context manager for backends be a reasonable alternative.

I don't think there is anything else one would want to do within the context manager other than doing the save, which suggests that factoring out the backend switching is not worth it.

Do we need checks that the format/extension and the backend are compatible?

This has been added per@tacaswell's suggestion.

@anntzer thanks for the clarification.

I believe not (the backend-dependent logic is in draw(), which is only called by savefig()).

Are use cases affected that use an intermediate draw to get some position information and use that to position subsequent elements?

Backend switching is subject to the same rules as use() (i.e. you cannot switch to an interactive backend requiring a GUI event loop once another GUI event loop is running). But switching to a noninteractive backend is fine (and the intended use case)

Something like this should be explicitly mentioned in the docstring of the backend parameter; maybe even with a list of supported builtin backends.

The other points are ok.

Are use cases affected that use an intermediate draw to get some position information and use that to position subsequent elements?

You'd run into the same issues (if any) as if saving to pdf from an interactive canvas, so nothing new.

Something like this should be explicitly mentioned in the docstring of the backend parameter; maybe even with a list of supported builtin backends.

done.

@anntzer Thanks for this work! Does the PR include asavefig.backend rcParams (it does not seems so), and if not could it be possible to add one?

It doesn't and fwiw I still don't like the idea.

Doc failures look real:

/home/circleci/project/lib/matplotlib/figure.py:docstring of matplotlib.figure.Figure.savefig:98: WARNING: Unknown target name: "the-builtin-backends"./home/circleci/project/lib/matplotlib/pyplot.py:docstring of matplotlib.pyplot.savefig:98: WARNING: Unknown target name: "the-builtin-backends"./home/circleci/project/lib/matplotlib/backend_bases.py:docstring of matplotlib.backend_bases.FigureCanvasBase.print_figure:42: WARNING: Unknown target name: "the-builtin-backends".

doc build fixed