you can pickle the figure. that is basically equivalent to the .fig format.

you can pickle the figure. that is basically equivalent to the .fig format.

This can be an option, then it would be nice to incorporate this inside the savefig method.

not a terrible idea. I wonder what the extension should be? ".pkl"? ".pckl"?

I see a major advantage for a complete interface - in the sense of saving and loading a pickled figure: A major disadvantage of pickling is that a figure needs to be opened with the same version of matplotlib that was used to save it. With a dedicated interface one could write that version to an attribute of the figure; upon loading one could read it, compare to the actual version and inform the user in case of a conflict. This will allow them to know about the reason for failure as well as to a possible workaround (e.g. quickly get the version needed into a new conda env).

This can be an option, then it would be nice to incorporate this inside the savefig method.

I proposed this 5 years ago in #3819 (well, it's from the UI but that exposes the same filetypes as savefig so it's really the same idea) and that was rejected by @tacaswell and also by @WeatherGod :) and again in #9357. See https://github.com/jnothman/pickleback for a 3rd-party solution though (I personally use a variant of that as well).

With a dedicated interface one could write that version to an attribute of the figure [...] inform the user in case of a conflict

This is already done:

What is the rationale for such a feature? Extremely skeptical that it’s a good idea. If the figure is expensive, reading and writing it will be expensive. If the analysis is expensive, save intermediate data. If you are doing a lot of work interactively, that’s not at all reproducible, and you will be deeply unhappy with yourself when someone asks you to change the analysis.

@anntzer, at the time, the pickling feature was very new, and we kept getting bug reports about it. In the 5 years since, it is more stable. Now, I am not saying that it is up to the quality and robustness of matlab's .fig, but I wouldn't be opposed to someone putting in the effort to make it better and then make it a first-class citizen alongside .png, .jpeg, etc.

I think I buy the security argument. Someone writing pickle.load(open("filename.pkl", "rb" )) will be much more aware of the fact that they absolutely need to trust the source of that file, compared to someone writing plt.loadfigure("filename.mplfig") or similar.
On the other hand, implementing a dedicated file format around the pickle would allow for additional security features (encryption, hashing, etc.) that might make such file as secure as any other executable you decide to run on your computer.

@jklymak

What is the rationale for such a feature? Extremely skeptical that it’s a good idea. If the figure is expensive, reading and writing it will be expensive. If the analysis is expensive, save intermediate data. If you are doing a lot of work interactively, that’s not at all reproducible, and you will be deeply unhappy with yourself when someone asks you to change the analysis.

Definitively when generating a plot with expensive analysis, you must save the important data. But sometimes you want to modify the plot style, names, labels... because when you generated the graph you did it quickly and you were just trying a new thing. This can be useful to prepare the plot for a slide presentation.

Also, it can be useful to be able to send the figure to another person without having to send him the whole script and data. Anyway it is always useful to have this feature, and I am sure people will take a good profit of this.

Definitively when generating a plot with expensive analysis, you must save the important data. But sometimes you want to modify the plot style, names, labels... because when you generated the graph you did it quickly and you were just trying a new thing. This can be useful to prepare the plot for a slide presentation.

Sure, but again, its really just as easy to re-run the plotting script and, in all likelihood, faster.

I think I buy the security argument. Someone writing pickle.load(open("filename.pkl", "rb" )) will be much more aware of the fact that they absolutely need to trust the source of that file, compared to someone writing plt.loadfigure("filename.mplfig") or similar.

We don't need to provide a specific loader and can (in fact, probably should) just leave pickle.load as the way to load a figure pickle. Thus I don't think this is a security problem beyond the well known security problem of pickles.

@anntzer, you are assuming it is a well-known issue, but I can guarantee you that it isn't well-known among non-developers, and maybe only half-known among python developers, given the number of times I have raised such issues in code reviews at work. There is nothing wrong with educating users in the documentation about the potential security risks of loading an ".mplfig" from an untrusted source.

My point is more "we should call it .pkl or .pickle and only educate users once about pickles, not hide it as a different extension and pretend it's something different".

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

Serialization is still something we want, but not sure if it'd be better to open a new issue starting from current state of the library.