The bug occurs when the pickle is loaded with mpl in interactive mode, and not otherwise, at least in my limited testing. I think the problem is that in interactive mode, draw() commands are triggered before the unpickling is complete. Conceptually, this could be solved if draw_if_interactive() had a way of knowing that unpickling is in progress; equivalently, a solution would be for the unpickling process to turn off interactive mode until it has finished. Offhand, I don't know how to implement either of these solutions. Does pickle.load set a global variable that serves as a flag to show when loading is in progress?

If not, then maybe we need to have a pickle.load wrapper in mpl, and tell people to use that instead of raw pickling. As a step beyond that, we could have a pickle.save wrapper, and potentially add metadata to the file.

@mdepitta in the meantime, a workaround for you is manually turn interactive mode off (plt.ioff()) before loading your pickle, and restore it (plt.ion(), if you were indeed in interactive mode) at the end.

Or, instead of a wrapper around pickle.load(), how about a context manager?

On Sun, Sep 7, 2014 at 4:06 PM, Eric Firing notifications@github.com
wrote:

The bug occurs when the pickle is loaded with mpl in interactive mode, and
not otherwise, at least in my limited testing. I think the problem is that
in interactive mode, draw() commands are triggered before the unpickling
is complete. Conceptually, this could be solved if draw_if_interactive()
had a way of knowing that unpickling is in progress; equivalently, a
solution would be for the unpickling process to turn off interactive mode
until it has finished. Offhand, I don't know how to implement either of
these solutions. Does pickle.load set a global variable that serves as a
flag to show when loading is in progress?

If not, then maybe we need to have a pickle.load wrapper in mpl, and tell
people to use that instead of raw pickling. As a step beyond that, we could
have a pickle.save wrapper, and potentially add metadata to the file.

@mdepitta https://github.com/mdepitta in the meantime, a workaround for
you is manually turn interactive mode off (plt.ioff()) before loading
your pickle, and restore it (plt.ion(), if you were indeed in interactive
mode) at the end.

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

@WeatherGod Yes, a context manager would work. A disadvantage is that context managers are relatively new features of Python, and not something a beginner or casual user (or perhaps an old-timer like myself) is likely to have at their fingertips. With a pair of wrappers we could provide a simple function interface with memorable names (really, if you were a beginner, would you think of using the term "pickle" for saving a plot?), and with the ability to improve functionality via metadata and error handling. In fact, we could add the pickling capability to the savefig method and function, and then add a restorefig function, or something like that.
I've never been a fan of this general approach; instead I've always advocated using scripts to save code and data as needed to recreate plots. Nevertheless, we have the pickle capability, and there is always demand for this style, so we are stuck with it. Might as well try to make it easy to use.
An argument to the contrary would be that because pickles only work for short-term storage when one can be sure of restoring into the same environment as that from which one saved, we should let our pickle capability remain obscure; otherwise we might be inundated with complaints that "I can't load the pickle I saved last year." So, maybe we are better off just providing a context manager in pyplot.
I'm undecided.

I would advocate against pushing the use of pickle to store/share plots due to the security issues associated with them.

This will hopefully be addressed by the effort to serialize figures to json.

Wow, I'm so behind on my notifications! Thanks for raising this @mdepitta. Can you provide a SSCCE (Short, Self Contained, Correct , Example) to allow us to reproduce? This will dramatically speed up the development of a fix for this issue.

Thanks!

Given the "won't fix" decision, I'm going to close this.