On Sun, Oct 29, 2017 at 10:04 AM, Simon King <simon.k...@uni-jena.de> wrote: > Hi Erik, > > On 2017-10-27, Erik Bray <erik.m.b...@gmail.com> wrote: >> Plus, while pickling has many valid runtime use-cases, particularly >> for IPC, and short-term preservation of objects between interpreter >> sessions, it was *never* intended for long-term data storage, > > Seriously? Said who? > > I always thought of pickles as the default way to store the results > of long computations, for later (potentially MUCH later) use. Of course, > it always is possible to say "install an old software version to unpickle > the results" or "write a routine that allows to read the old pickle in > a new software version", but as part of user-friendliness, I would > recommend that SageMath-developers keep considering it as their duty to > make unpickling backward-compatible, to a reasonable extent.
I'll see if I can find an "authoritative" source making this claim, but I believe it is conventional wisdom (along the lines of "goto considered evil"--it's not as if there aren't valid uses for it but it should be avoided unless you know what you're doing). My point, however, is baked directly into the file format--the pickle format is very Python version-dependent (there are I think 5 different pickle formats now) and the way non-trivial objects are pickled is highly tied to the version of the source code at which that pickled object was saved. It depends on the module layout, class names, implementation of that object's __reduce__ at the time the pickle was made, etc. So while you can use pickle for long-term storage, it's implicit in the format that if you want to unpickle an object saved at a given time, you may need to be running the same version of the software at which the pickle was created (it might be nice if there were somehow a way to mark this explicitly when pickling Sage objects, e.g. with the current git hash). Anyways, as I wrote for short-term storage (e.g. results of long computations that will be reused later in the same software) it's fine. For long-term you want a more transparent, more interoperable serialization format. JSON isn't sufficient for all uses cases, but there are other alternatives as well, even for binary data. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
