You can already pickle figure objects. Did you mean something more than this?

import numpy as np
import matplotlib.pyplot as plt
import pickle as pl

fig, ax = plt.subplots()
x = np.linspace(0,2*np.pi)
y = np.sin(x)
ax.plot(x,y)

# Save figure handle to disk
pl.dump(fig, file('figure.pickle', 'wb'))

I mean that fig.savefig('out.pkl') should be supported. Thus if I have a command-line script, for instance, which saves a series of figures to disk at specified paths, I need only provide a pkl extension for it to dump something I can still interact with, or modify before rendering to image.

FWIW a similar idea was rejected at #3819 (and I now agree with the rationale there).

In practice this can easily be implemented by adding a print_pkl method on the canvas (see backend_bases.py):

canvas = plt.gcf().canvas
canvas.print_pkl = lambda fname, **kwargs: pickle.dump(canvas.figure, open(fname, "wb"))
plt.savefig("...")

which you can nicely wrap in an enable_pkl or whatever function.

You can explicitly pass a format to savefig, the only question is whether to actively encourage people to save pickles. Right now we are definitely not making guarantees for cross-version compatibility of pickles, which is IMO the main argument for not encouraging their use.

Alternatively, you can just patch the print_pkl method into FigureCanvasBase (e.g. you may have a utils module that you generally import? just import matplotlib and patch it from there) and be done with it.

👎 we keep the pickle support working primarily to support multi-process work (for the case where you have and expensive to generate, but small at the end figure).

Please do not patch FigureCanvasBase on import.

See http://matplotlib.org/tutorials/introductory/usage.html#backends If you have custom sub-class of your backend of choice that provides pkl you can just do matplotlib.use("module://pickle_of_doom").

I'm still not following why pickle.dump is any worse than figure.savefig.

@jklymak because I already have scripts using savefig. Let's make it more tangible. I'd written my scripts to use savefig for experimental analysis. Now I want to publish some of them. Rather than go hack my code, I'd like to just specify a different path, one that ends in .pkl. Then it should behave as I seek transparently.

Thanks @tacaswell, I've realised a module:// backend is acceptable, as long as my base backend is consistent across platforms I want to apply this on. If I want to provide it as a tool for others to use, well, then, that's not really sufficient without having a way to allow the user to configure a base backend for my tool, and so the madness ensues (thus flat is better than nested).

Having a script which allows me to run other scripts in a context in which FigureCanvasBase, or at least the current backend, is patched is more portable.

But then why would you not just offer me a way to register a backend just for one extension in my matplotlibrc?

PS: yes, it's useful for multiprocessing; here it is for incremental processing, where similarly the figure(s) may be expensive to generate (or depends on data that is expensive to load or aggregate).

Use http://matplotlib.org/api/backend_bases_api.html?highlight=register_backend#matplotlib.backend_bases.register_backend that should be safe to do on import of your module.

I've not yet played with it much, but here's the result of this conversation: https://github.com/jnothman/pickleback. I have a problem where a pickled figure is restored with its canvas attribute set to None and I do not understand why. Insights are welcome.