[sage-devel] Getting rid of the pickle jar

[Jeroen Demeyer]

This is a topic which comes up now and then but which hasn't been 
resolved so far.


Sage has a "pickle jar" stored in src/ext/pickle_jar/pickle_jar.tar.bz2 
and there are tests in src/sage/structure/sage_object.pyx which check 
that every object in the pickle jar can be unpickled without raising an 
exception.


The theory is that this ensures that people having old pickles on their 
machines can still use them with newer versions of Sage. However, the 
pickle jar does not achieve this goal because


(1) The doctest only tests that the pickles can be unpickled. There are 
no tests that the unpickled objects still function correctly. See 
https://trac.sagemath.org/ticket/16311


(2) Nobody adds new pickles to the pickle jar. The last time that a 
pickle was added was in 2011. So, if anything, it only tests that 
pickles which are at least 6 years old still work correctly.


Since the pickle jar doesn't do what it is meant to do, I suggest to be 
pragmatic and remove it completely.


Having the pickle jar is a burden for development because it prevents 
certain refactorings or removals. For example finite_field_ext_pari.py 
was deprecated in 2014 but we cannot remove it because it breaks the 
pickle jar. I know that I could probably fix this with 
register_unpickle_override() but that feels a waste of time because I 
wonder if anybody really cares. In the mean time, people need to 
maintain that unused deprecated file to make it Python 3 compatible for 
example.


I'm sure that some people have suggestions for improving the pickle jar 
procedure. But still, the fact remains that many pickles in the current 
pickle jar are broken. So there is no point in keeping them.



Thoughts?
Jeroen.

--
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.

[sage-devel] Re: Getting rid of the pickle jar

[Jean-Pierre Flori]

Remove it.

-- 
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.

Re: [sage-devel] Getting rid of the pickle jar

[Erik Bray]

On Fri, Oct 27, 2017 at 10:42 AM, Jeroen Demeyer  wrote:
> This is a topic which comes up now and then but which hasn't been resolved
> so far.
>
> Sage has a "pickle jar" stored in src/ext/pickle_jar/pickle_jar.tar.bz2 and
> there are tests in src/sage/structure/sage_object.pyx which check that every
> object in the pickle jar can be unpickled without raising an exception.
>
> The theory is that this ensures that people having old pickles on their
> machines can still use them with newer versions of Sage. However, the pickle
> jar does not achieve this goal because
>
> (1) The doctest only tests that the pickles can be unpickled. There are no
> tests that the unpickled objects still function correctly. See
> https://trac.sagemath.org/ticket/16311
>
> (2) Nobody adds new pickles to the pickle jar. The last time that a pickle
> was added was in 2011. So, if anything, it only tests that pickles which are
> at least 6 years old still work correctly.
>
> Since the pickle jar doesn't do what it is meant to do, I suggest to be
> pragmatic and remove it completely.
>
> Having the pickle jar is a burden for development because it prevents
> certain refactorings or removals. For example finite_field_ext_pari.py was
> deprecated in 2014 but we cannot remove it because it breaks the pickle jar.
> I know that I could probably fix this with register_unpickle_override() but
> that feels a waste of time because I wonder if anybody really cares. In the
> mean time, people need to maintain that unused deprecated file to make it
> Python 3 compatible for example.
>
> I'm sure that some people have suggestions for improving the pickle jar
> procedure. But still, the fact remains that many pickles in the current
> pickle jar are broken. So there is no point in keeping them.

+1

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, in part
precisely because it's directly tied to the source code that was used
to produce the pickle file.  The only truly "correct" way to restore
old pickled objects is to do so with the same version of the software
the pickle was created with.

If there does not yet exist, and/or is need for better serialization
formats for objects in Sage that's something worth talking seriously
about (I feel like the MitM work being done is to this effect though).
But pickle ain't it!

-- 
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.

[sage-devel] Re: Proposal : a branch for OpenSSL-less Sage

[Maarten Derickx]

Why a separate git branch and not make it something configurable, like 
building sage with gmp vs mpir?

On Wednesday, 25 October 2017 18:01:00 UTC+2, Emmanuel Charpentier wrote:
>
> The recent vote on the inclusion of OpennSSL in Sage has shown that some 
> Sage developers [wished](
> https://groups.google.com/d/msg/sage-devel/fE45025Wphs/mKdCAeNhAgAJ) to 
> keep the ability to build Sage without dependence on this contentious 
> library.
>
> I think that this can be implemented, thanks to Git, in the following 
> manner :
> * Prepare a branch (let's say `anchorite`).
> * Follow the [Trac ticket](https://trac.sagemath.org/ticket/24107) aiming 
> at the inclusion of OpenSSL
> * At this ticket merge into Sage, revert the pertinent commits in 
> `anchorite`
> * At each point you want to release, merge with the branch you wish to 
> reach to in `master` or `develop`, and reverse again.
> * If new additions or patches rely on the presence of OpenSSL, add them to 
> your set of patches to be reversed, rinse and repeat...
>
> In short, the delta between `master` or `develop` and `anchorite` will be 
> the sum of patches reversal involvig OpenSSL.
>
> This is easy to do for people using git as thei source. The problem is not 
> so simple to release tarballs or binaries : a synchronization with the 
> release manager is necessary. And I haven't the foggiest idea on how to 
> proceed, for lack of knowledge of the release process.
>
> No ,proposal ticket (yet), since this is mainly an organizational issue...
>
> Your inputs, please ?
>
> --
> Emmanuel Charpentier
>
>

-- 
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.

[sage-devel] Re: Proposal : a branch for OpenSSL-less Sage

[Emmanuel Charpentier]

Dear Marteen,

Le vendredi 27 octobre 2017 16:02:03 UTC+2, Maarten Derickx a écrit :
>
> Why a separate git branch and not make it something configurable, like 
> building sage with gmp vs mpir?
>

Because those are not the same cases :

a) there is no currently (to the best of my limited knowledge) , strong 
reasons to choose one over the other,
b) they give (modulo my limited knoiwledge, again) roughly the same 
possibilities to Sage,
c) there are people able, and **volunteering**, to maintaint this 
alternative.

In the case of OpenSSL not having OpenSSL:

a) doesn't give us anything but the ability to do without a package deemed 
"GPL incompatible" (in the sense that we currently cannot ship it  with 
Sage)
b) deprives R and pip users of an useful ability (deemed mandatory by R 
authors)
c) forces us to maintain a patch that is of no use to what I think a 
majority of Sage users.

The point made by William about security issues is also to be considered ; 
but I'm not an expert...

--
Emmanuel Charpentier

-- 
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.

Re: [sage-devel] Online Sage Days

[Emmanuel Charpentier]

Le jeudi 26 octobre 2017 10:54:01 UTC+2, Dr. David Kirkby (Kirkby Microwave 
Ltd) a écrit :
>
> On 9 September 2017 at 10:04, David Roe > 
> wrote:
>
>> Hi everyone,
>> I'd like to organize some online Sage Days, where people gather on 
>> zulip.sagemath.org and work on Sage together.  The two things to be 
>> decided are 
>>
>  
> Sounds good.  
>
> 1. What topics should we focus on?
>> 2. What days/times work for the most people?
>> Some of these may transition into in-person working groups (the IMA has 
>> funding for small groups to meet there over this coming year to work on 
>> projects)
>>
>
> I look at a large number of online webinars from companies like Rohde and 
> Schwarz, Keysight etc. They always seem to arrange them afternoon in the 
> USA, so they are at a reasonable time in the day for Europe too. 
>
>  
>
>>
>> I'll send out a survey for the scheduling part, but I wanted to solicit 
>> suggestions for topics first.  Some ideas:
>>
>>
>> If you'd like me to include other topics in the survey, chime in!
>> David
>>
>
> * Some for absolute beginners - it makes sense to make that the first of 
> these. 
> * Some for engineers, or others who don't have maths degrees. 
> * Some for developers.
>

The last two subsets should *NOT* be disjoint. Sage may hugely benefit from 
enhancements in the "undergrad maths/engeneering" and "general 
infrastructure" departments, if only to recruit new non-math-major users, 
some of which may become developers in those domains nott exclusively 
focused on number theory or abstract algebra

(BTW : enhancements in the abstract algebra department focused towards 
undergrads would be useful, too...)
 

> I used to do a lot of work for Sage - in fact I was at one point in the 
> top 10% of some list William produced. But now the switch from mercurial to 
> git, and I'm out of it. There are other reasons in my case - I worked 
> mainly on the port to Solaris, completed that, but Solaris is no longer 
> tested or working. 
>

Should it be rekindled ? Or should we stop to claim to support Solaris ?

BTW : is Solaris still a live platform ?
 

> * A DECENT interface to Mathematica, with a proper API, not using pexpect, 
> which seems to be rather a poor alternative, which is always breaking. 
>

A good interface to "the competition" is always useful. However, I wouldn't 
disdain pexpect, which turns out to be surpisingly useful. The current 
(non-negligible) problems with Mathematica interface seem more related to 
the lack of proper dictionaries and support functions in Sage (where there 
are in fact functions to *guess* (!) a translation) than a fundamental 
interface type problem. A real pair of parsers for what we send  to 
Mathematica and what it returns could be a useful first step...
 

> * NOT OpenSSL. 
>

Please. Problem solved. Implementation underway...

--
Emmanuel Charpentier

-- 
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.

Re: [sage-devel] Implementation plan : inclusion of OpenSSL

[Emmanuel Charpentier]

Le mercredi 25 octobre 2017 21:37:59 UTC+2, Michael Orlitzky a écrit :
>
> On 10/25/2017 12:14 PM, Emmanuel Charpentier wrote: 
> > Can you explain how the Wget case is different from ours ? 
>
> A single entity (the FSF) owned the copyright on all of the code in wget 
> when they changed the license to add the exception. The same is not true 
> of SageMath: we don't have copyright assignment, and we bundle a lot of 
> code that is copyrighted by complete strangers. 
>

Okay : I'm not still convinced, but I'll follow you on a "primum non 
nocere" basis.

If we follow you, we have to take back any talk of *inclusion* right now. 
The solution is to depend *unconditionally* on a systemwide OpenSSL and 
stop building if not found, possibly hinting at steps to that effect.

*After* OpenSSL relicensing, we can introduce a standard openssl package, 
whith no huffing and puffing.

Now, all that I miss is a hint to give to people wanting to build sage 
*withut* OpenSSL. Since we get rid oif the current anti-OpenSSL patches, We 
ncan't let these users hang dry...

--
Emmanuel Charpentier

--
Emmanuel Charpentier 

-- 
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.

Re: [sage-devel] Proposal : a branch for OpenSSL-less Sage

[Emmanuel Charpentier]

Le jeudi 26 octobre 2017 11:57:44 UTC+2, Erik Bray a écrit :
>
> On Wed, Oct 25, 2017 at 6:31 PM, Emmanuel Charpentier 
> > wrote: 
> > 
> > 
> > Le mercredi 25 octobre 2017 18:10:02 UTC+2, Jeroen Demeyer a écrit : 
> >> 
> >> On 2017-10-25 18:01, Emmanuel Charpentier wrote: 
> >> > Your inputs, please ? 
> >> 
> >> I think it is completely pointless. And it's never going to work in 
> >> practice... nobody is going to want to maintain that branch. 
> > 
> > 
> > Maybe people that think that it is oh, sooo important to be able to 
> build 
> > Sage without (Open)SSL support, that they want us to maintain patches 
> > _agains_ software that _needs_ SSL ? 
>
> Hi there, 
>
> No need for the exaggeration.  I don't personally think it's so 
> important to be able to build Sage without SSL support.


So do I ;-). But some people think it is important, and they may have a use 
case where they are right.
 

> For myself I 
> don't care, because I will never be affected by this issue.  As I keep 
> saying R is the only package giving us any trouble at all at the 
> moment, and in insisting that R should be able to build without SSL 
> I'm only trying to help *you*.
>

This I understood. I'm just 
a) extremely skeptic about the possibility of haviog the R Core Team 
reverse its decision, and
b) skeptic about the usefulness of reversing a decision tha aims to offr a 
(slightly) enhanced security.

You don't want to have to "maintain a 
> patch" and I'm just saying ideally nobody should have to patch R just 
> to be able to build it without an effectively optional dependency :) 
>
> Heck, go ahead even and drop that patch if you want, just as long as 
> there are clear instructions for OSX users how to build. 
>

Indeed : I'm relying on people with knowledge of Mac OS X and its 
shenanigans (a. k. a. "our Mac heads") for that.

PS : since I've modified my plans 
 a 
bit, I'll need to give a hint to people who insist on building Sage 
(including R) without OpenSSL. That was my point in suggesting a dedicated 
branch. Do you have alternatives to suggest ?

Sincerely yurs,

--
Emmanuel Charpentier

-- 
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.

Re: [sage-devel] Online Sage Days

[William Stein]

On Fri, Oct 27, 2017 at 7:46 AM Emmanuel Charpentier <
emanuel.charpent...@gmail.com> wrote:

> I used to do a lot of work for Sage - in fact I was at one point in the
>> top 10% of some list William produced. But now the switch from mercurial to
>> git, and I'm out of it. There are other reasons in my case - I worked
>> mainly on the port to Solaris, completed that, but Solaris is no longer
>> tested or working.
>>
>
> Should it be rekindled ? Or should we stop to claim to support Solaris ?
>

I personally no longer care about Solaris support for Sage.   We used to
support Solaris before mainly because a paying customer paid us something
(which made it possible for Michael Abshoff to work on Sage).  They are no
longer paying us, and haven't for many, many year.


>
>> * A DECENT interface to Mathematica, with a proper API, not using
>> pexpect, which seems to be rather a poor alternative, which is always
>> breaking.
>>
>
> A good interface to "the competition" is always useful. However, I
> wouldn't disdain pexpect, which turns out to be surpisingly useful. The
> current (non-negligible) problems with Mathematica interface seem more
> related to the lack of proper dictionaries and support functions in Sage
> (where there are in fact functions to *guess* (!) a translation) than a
> fundamental interface type problem. A real pair of parsers for what we
> send  to Mathematica and what it returns could be a useful first step...
>

Emmanuel, you really understand Sage...

William
-- 
-- William Stein

-- 
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.

Re: [sage-devel] Implementation plan : inclusion of OpenSSL

[Michael Orlitzky]

On 10/27/2017 10:53 AM, Emmanuel Charpentier wrote:
> 
> Okay : I'm not still convinced, but I'll follow you on a "primum non
> nocere" basis.
> 
> If we follow you, we have to take back any talk of *inclusion* right
> now. The solution is to depend *unconditionally* on a systemwide OpenSSL
> and stop building if not found, possibly hinting at steps to that effect.

That's what I would recommend. Otherwise, anyone distributing the
SageMath code or binaries is putting themselves at risk. Or more likely,
we're putting them at risk -- because I doubt many mirror operators are
following this discussion.

There are two separate issues with bundling:

  a) distributing SageMath binaries linked against a non-system copy of
 OpenSSL

  b) distributing the source for "SageMath the distribution," which
 sort-of includes a copy of the OpenSSL code

Linking creates a derivative work (most people agree on this), so the
resulting binaries in (a) cannot be distributed: doing so would violate
the GPL, because anyone receiving a copy would be subject to the
additional restrictions from the OpenSSL license.

The OpenSSL source code is no longer in our git repo; we do however ship
an SPKG that automatically downloads and patches the OpenSSL source to
integrate it with the rest of SageMath. Whether or not that creates a
non-distributable derivative work, I don't know -- but I would err on
the side of caution.

And don't forget that end users are free to do whatever they want. If we
tell them to download the OpenSSL tarball, patch it, and to put the
result somewhere in $SAGE_ROOT before running "make", then neither (a)
nor (b) is happening. That's perfectly legal, even though it makes the
argument in the previous paragraph look stupid (I went into math and not
law for a reason). The only "gotcha" there is that end users would not
be able to redistribute the resulting SageMath binaries, for the same
reason that we can't



> *After* OpenSSL relicensing, we can introduce a standard openssl
> package, whith no huffing and puffing.

Right, but I'm sceptical that it will happen. If it does, how long are
we willing to wait?

Requiring a system copy is the best solution, if for no other reason,
then because nobody will have to read any more long emails about it.

-- 
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.

Re: [sage-devel] Getting rid of the pickle jar

[Travis Scrimshaw]

On Friday, October 27, 2017 at 10:19:31 PM UTC+10, Erik Bray wrote:
>
> On Fri, Oct 27, 2017 at 10:42 AM, Jeroen Demeyer  > wrote: 
> > This is a topic which comes up now and then but which hasn't been 
> resolved 
> > so far. 
> > 
> > Sage has a "pickle jar" stored in src/ext/pickle_jar/pickle_jar.tar.bz2 
> and 
> > there are tests in src/sage/structure/sage_object.pyx which check that 
> every 
> > object in the pickle jar can be unpickled without raising an exception. 
> > 
> > The theory is that this ensures that people having old pickles on their 
> > machines can still use them with newer versions of Sage. However, the 
> pickle 
> > jar does not achieve this goal because 
> > 
> > (1) The doctest only tests that the pickles can be unpickled. There are 
> no 
> > tests that the unpickled objects still function correctly. See 
> > https://trac.sagemath.org/ticket/16311 
> > 
> > (2) Nobody adds new pickles to the pickle jar. The last time that a 
> pickle 
> > was added was in 2011. So, if anything, it only tests that pickles which 
> are 
> > at least 6 years old still work correctly. 
> > 
> > Since the pickle jar doesn't do what it is meant to do, I suggest to be 
> > pragmatic and remove it completely. 
> > 
> > Having the pickle jar is a burden for development because it prevents 
> > certain refactorings or removals. For example finite_field_ext_pari.py 
> was 
> > deprecated in 2014 but we cannot remove it because it breaks the pickle 
> jar. 
> > I know that I could probably fix this with register_unpickle_override() 
> but 
> > that feels a waste of time because I wonder if anybody really cares. In 
> the 
> > mean time, people need to maintain that unused deprecated file to make 
> it 
> > Python 3 compatible for example. 
> > 
> > I'm sure that some people have suggestions for improving the pickle jar 
> > procedure. But still, the fact remains that many pickles in the current 
> > pickle jar are broken. So there is no point in keeping them. 
>
> I am also +1 if there are no issues with the notebooks or CoCalc. Although 
I do not think this affects them because inorder to use the objects, I have 
to recreate them instead of having them being (functionally) persistent 
across sessions.

>
> 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, in part 
> precisely because it's directly tied to the source code that was used 
> to produce the pickle file.  The only truly "correct" way to restore 
> old pickled objects is to do so with the same version of the software 
> the pickle was created with. 
>

The TestSuite does a standard pickle/unpickle test for this and IMO every 
object should have at least one TestSuite(foo).run() test (typically in its 
__init__ method). We have also made it easier with git tags to revert to 
previous versions of Sage and then if you really need your object, you can 
translate it into key data in a file that you can then read back and 
reconstruct in the later version if the pickling has broken in the 
meantime. While this means we are less backwards compatible, I think this 
will not affect too many (any?) users, or at least make then not quit using 
Sage.
 
Best,
Travis
 

-- 
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.

Re: [sage-devel] Getting rid of the pickle jar

[William Stein]

On Fri, Oct 27, 2017 at 5:47 PM Travis Scrimshaw  wrote:

>
>
> On Friday, October 27, 2017 at 10:19:31 PM UTC+10, Erik Bray wrote:
>
>> On Fri, Oct 27, 2017 at 10:42 AM, Jeroen Demeyer 
>> wrote:
>> > This is a topic which comes up now and then but which hasn't been
>> resolved
>> > so far.
>> >
>> > Sage has a "pickle jar" stored in src/ext/pickle_jar/pickle_jar.tar.bz2
>> and
>> > there are tests in src/sage/structure/sage_object.pyx which check that
>> every
>> > object in the pickle jar can be unpickled without raising an exception.
>> >
>> > The theory is that this ensures that people having old pickles on their
>> > machines can still use them with newer versions of Sage. However, the
>> pickle
>> > jar does not achieve this goal because
>> >
>> > (1) The doctest only tests that the pickles can be unpickled. There are
>> no
>> > tests that the unpickled objects still function correctly. See
>> > https://trac.sagemath.org/ticket/16311
>> >
>> > (2) Nobody adds new pickles to the pickle jar. The last time that a
>> pickle
>> > was added was in 2011. So, if anything, it only tests that pickles
>> which are
>> > at least 6 years old still work correctly.
>> >
>> > Since the pickle jar doesn't do what it is meant to do, I suggest to be
>> > pragmatic and remove it completely.
>> >
>> > Having the pickle jar is a burden for development because it prevents
>> > certain refactorings or removals. For example finite_field_ext_pari.py
>> was
>> > deprecated in 2014 but we cannot remove it because it breaks the pickle
>> jar.
>> > I know that I could probably fix this with register_unpickle_override()
>> but
>> > that feels a waste of time because I wonder if anybody really cares. In
>> the
>> > mean time, people need to maintain that unused deprecated file to make
>> it
>> > Python 3 compatible for example.
>> >
>> > I'm sure that some people have suggestions for improving the pickle jar
>> > procedure. But still, the fact remains that many pickles in the current
>> > pickle jar are broken. So there is no point in keeping them.
>>
>> I am also +1 if there are no issues with the notebooks or CoCalc.
> Although I do not think this affects them because inorder to use the
> objects, I have to recreate them instead of having them being
> (functionally) persistent across sessions.
>

There is definitely no issue with CoCalc.


>> 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, in part
>> precisely because it's directly tied to the source code that was used
>> to produce the pickle file.  The only truly "correct" way to restore
>> old pickled objects is to do so with the same version of the software
>> the pickle was created with.
>>
>
> The TestSuite does a standard pickle/unpickle test for this and IMO every
> object should have at least one TestSuite(foo).run() test (typically in its
> __init__ method). We have also made it easier with git tags to revert to
> previous versions of Sage and then if you really need your object, you can
> translate it into key data in a file that you can then read back and
> reconstruct in the later version if the pickling has broken in the
> meantime. While this means we are less backwards compatible, I think this
> will not affect too many (any?) users, or at least make then not quit using
> Sage.
>

If we were to get rid of the pickle jar, then we should also add
documentation (e.g., for the save/load functions, which save/load objects),
saying -- basically -- do not trust this at all, except for ephemeral
movement of objects, unless you are sure to keep the specific version of
sage you used around.   We should say that we gave up and decided not to
put even the slightest effort into making save/load work over time.

William


>
> Best,
> Travis
>
>
> --
> 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.
>
-- 
-- William Stein

-- 
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.