I am against this. Pickles are not really meant for this for both technical and security reasons.

They can be used to run malicious code in a way you have no chance to audit. Getting users used to the idea of loading pickles from others is not a good idea.

They rely on internal details of mpl object we think are private and can change on a bug fix release. Supporting pickles as the default serialization would basically fix the current object structure and greatly constrain future work.

What we really need is proper serialization which is on the radar. In the meantime, the recommendation is to us the script you used to generate the figure as the serialization.

What about enabling this only when verbose-debug is set? This would make the issues you've mentioned reasonably clear.
Using the script as serialization only works if there is a standalone script that generates the figure, not if it is part of a larger GUI app and involved various user inputs to be generated. (My goal is to use the app to generate the elements of the figure, then load the pickled figure in IPython to improve its layout/suitability for printing/etc.)

I am with Thomas on this one as a general rule, but, perhaps this could be
somewhat mitigated by the tools refactor that is currently being done. If I
understand it correctly, it would become easier for users to add tools to
their figures. Perhaps, as you suggest, activated by the verbose-debug mode
turned on?

On Thu, Nov 20, 2014 at 12:46 PM, Antony Lee notifications@github.com
wrote:

What about enabling this only when verbose-debug is set? This would make
the issues you've mentioned reasonably clear.
Using the script as serialization only works if there is a standalone
script that generates the figure, not if it is part of a larger GUI app and
involved various user inputs to be generated. (My goal is to use the app to
generate the elements of the figure, then load the pickled figure in
IPython to improve its layout/suitability for printing/etc.)

—
Reply to this email directly or view it on GitHub
#3819 (comment)
.

In that case I would advocate putting all of your plotting in to functions
that have signatures like g(ax, data, style) (data and style here can be
any combination of args and kwargs). You can then keep track of the data
you collect and the functions you call on it and then manage your own
serialization as tuples of (function_name, data, style). Your script is
then:

ax = plt.gca()  # or where ever you want to get it from
for fun, d, s in my_serialization:
    fun(ax, d, s)

This is probably a more stable serialization anyway as now you can upgrade
your old figures if you want to and are not reliant and any of the
internal details of the artists used for plotting etc.

You could probably even do one better and only have to serialize a
reference to your raw data too.

This of course might be a major refactor on your end...

On Thu, Nov 20, 2014, 12:46 Antony Lee notifications@github.com wrote:

What about enabling this only when verbose-debug is set? This would make
the issues you've mentioned reasonably clear.
Using the script as serialization only works if there is a standalone
script that generates the figure, not if it is part of a larger GUI app and
involved various user inputs to be generated. (My goal is to use the app to
generate the elements of the figure, then load the pickled figure in
IPython to improve its layout/suitability for printing/etc.)

—
Reply to this email directly or view it on GitHub
#3819 (comment)
.

The requirement for a major refactor on my side (well, not so major in fact), and the fact that now the saved figures would become dependent on a specific version of my program, are exactly the issues there.

Regarding the refactor, if this was to be implemented on the matplotlib side of things, I guess all we need is to add an entry in backends._default_{filetypes,backends} and define a print_pickle method on the backends. (In fact, now I feel like I should just patch matplotlib post-import for that...)

Regarding the version pinning, I would say that matplotlib is way more stable than anything I'll ever write, and it is much easier for me to write down "use matplotlib==1.4 to be load this figure" (at worst I need to set up a virtualenv) than "check out my code at commit g1234567 to load this figure".