[sage-devel] SAGE_LOCAL/include/libLfunction vs include/Lfunction
I am trying to understand the rationale behind this change in naming. In particular as most (all?) distributions, apart from Conda, that ship lcalc, use include/Lfunction rather than include/libLfunction. In particular this makes unvendoring lcalc unnecessary complicated, as both naming schemes have to be supported. https://trac.sagemath.org/ticket/28224 Can we go back to include/Lfunction (Conda can fix this, as Isuru says)? Thanks Dima -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq2po%3DXzujnvO8rPGcxKWLiu%3DZQb3PHe8XZfwfWdKdZF%3Dg%40mail.gmail.com.
[sage-devel] Re: SAGE_LOCAL/include/libLfunction vs include/Lfunction
Mon 2019-09-02 10:57:11 UTC, Dima Pasechnik: > > I am trying to understand the rationale behind this change in naming. > In particular as most (all?) distributions, apart from Conda, that > ship lcalc, use > include/Lfunction rather than include/libLfunction. > > In particular this makes unvendoring lcalc unnecessary complicated, as > both > naming schemes have to be supported. > https://trac.sagemath.org/ticket/28224 > Can we go back to include/Lfunction (Conda can fix this, as Isuru says)? > Note: after I posted on sage-packaging to point to the discussion here, some discussion is happening there: https://groups.google.com/d/topic/sage-packaging/xvh55IxHTZg -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/8ef32645-a0be-493d-81cc-717fd2d00d16%40googlegroups.com.
[sage-devel] Re: Unpickling problem (backwards incompatibility) in Python 3
On 2019-09-02, Simon King wrote:
> Strangely, when I read the pickle as a string
>open('path/to/file.sobj').read()
> then it fails with a (different?) UnicodeError in Python-3.
That's not the problem. However, I am not able to track down the problem
myself. So, I'd appreciate help.
I think I can show that the unpickling problem is NOT related with an
optional package. I believe being unable to read a pickle is a blocker
for the transition to Python-3. Therefore, I opened #28444.
Best regards,
Simon
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/qkje1o%24743i%241%40blaine.gmane.org.
Re: [sage-devel] Unpickling problem (backwards incompatibility) in Python 3
Hello Simon,
As discussed in
https://groups.google.com/forum/#!topic/sage-devel/JuKzzgxDlmA
Pickling/unpickling is not supposed to work accross Sage versions
(including the Python version you use).
Is this what you are trying to make work?
Vincent
Le 02/09/2019 à 02:25, Simon King a écrit :
Hi!
I have a pickle that I can unpickle in Sage-with-Python-2, but it fails
to unpickle in Sage-with-Python-3, because of some UnicodeError.
Strangely, when I read the pickle as a string
open('path/to/file.sobj').read()
then it fails with a (different?) UnicodeError in Python-3.
The details (namely the pickle and the steps to read it in Python-2) can
be found in https://trac.sagemath.org/ticket/28414#comment:36
Can some expert please tell me how to unpickle the pickle in Python-3?
Best regards,
Simon
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/fc4b783d-a421-e73e-88ab-395c9e401f7c%40gmail.com.
[sage-devel] Re: Unpickling problem (backwards incompatibility) in Python 3
On 2019-09-02, Vincent Delecroix <20100.delecr...@gmail.com> wrote: > As discussed in > > https://groups.google.com/forum/#!topic/sage-devel/JuKzzgxDlmA > > Pickling/unpickling is not supposed to work accross Sage versions > (including the Python version you use). > > Is this what you are trying to make work? The pickle that I posted at #28444 is of course not more than a small example and is a matter of seconds to reconstruct in Python-3. However, losing data that are the result of several months of computation would be hard to swallow. Also, if I understand the error message "UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0: ordinal not in range(128)" correctly, it is an error in unpickling a string. And this, I believe, can and must be totally absolutely backwards compatible. Cheers, Simon -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/qkjfjm%241r9o%241%40blaine.gmane.org.
[sage-devel] NTL 11.3.3
I've uploaded a new version of NTL. Details on changes are here: https://www.shoup.net/ntl/doc/tour-changes.html -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/9bc63254-7d6a-4cec-8e3a-0c004197a14f%40googlegroups.com.
[sage-devel] PGFFT
PGFFT is a "pretty good FFT" for double-precision complex numbers, written in C++. It's main selling points are (1) it's not too slow, and (2) it's available under a BSD license. Details here: https://www.shoup.net/PGFFT/ -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/19946e29-2933-4825-9a76-b98ea7ed2ca2%40googlegroups.com.
Re: [sage-devel] Re: error building barvinok (sage 8.9.beta8 + system NTL)
A clarification and a question... NTL's config system does not use a pre-built ibtool script. Rather, it builds a customized libtool by running a configure script on the host machine, so it should, in principle, be using a libtool script that is properly configured for the host machine. The configure script itself was built on a linux machine with up-to-date autotools using the following configure.ac file: AC_INIT(ntl-libtool, 1.0) AM_INIT_AUTOMAKE([foreign]) AC_CONFIG_FILES([Makefile]) LT_INIT AC_PROG_CXX AC_PROG_CC AC_PROG_LIBTOOL AC_OUTPUT I don't remember where I got this...but it was from somebody who seemed to know what they were talking about. Maybe the logic of this configure.ac file is not right? Any thoughts on this? On Wednesday, August 28, 2019 at 9:55:38 AM UTC-4, vdelecroix wrote: > > Victor, as far as I understand the main configuration script of ntl > is the perl DoConfig script. It has nothing to do with libtool. libtool > is robust if you let it handle the configuration. It will not try to > fix a given one. > > In a libtool configure.ac script you would just have a directive > AC_CHECK_LIB for pthread. > > In short, I would suggest > > 3) Replace DoConfig by a configure.ac script > > Vincent > > Le 28/08/2019 à 15:15, Victor Shoup a écrit : > > Thanks. I guess what I'm asking for is a solution. From what you say > here, > > and what is said in the links, the problem seems to be a bug in libtool, > > not NTL. So a solution would be, either: > > 1) a patch other type of libtool workaround, or > > 2) an alternative to libtool. > > I though the whole point of libtool was to take care of all this > nonsense, > > and if it's not doing that, then > > it seems kind of pointless. > > > > On Tuesday, August 27, 2019 at 1:42:51 PM UTC-4, Antonio Rojas wrote: > >> > >> > >> > >> El martes, 27 de agosto de 2019, 16:25:12 (UTC+2), Victor Shoup > escribió: > >>> > >>> I reviewed some comments which mentioned a problem with ntl and > threads. > >>> I’m happy to fix that, but I don’t think I understand what the issue > is. > >>> Can anyone explain? Thanks. > >> > >> > >> Hi Victor, > >> IIRC I reported this to you about a year ago. The problem is that you > are > >> using libtool as a build command, which calls the compiler with the > >> -nostdlib flag, which in turn overrides the -pthread flag, so the > binaries > >> end up not being linked to libpthread. See eg. [1][2] for more info. > >> > >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=661333 > >> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460 > >> > > > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/30264407-95c4-4057-a7a8-5dc0ea8b6437%40googlegroups.com.
Re: [sage-devel] Re: error building barvinok (sage 8.9.beta8 + system NTL)
On Mon, Sep 2, 2019 at 11:37 PM Victor Shoup wrote: > > A clarification and a question... > > NTL's config system does not use a pre-built ibtool script. Rather, it > builds a customized libtool by running a configure script on the host > machine, so it should, in principle, be using a libtool script that is > properly configured for the host machine. > > The configure script itself was built on a linux machine with up-to-date > autotools using the following configure.ac file: > > AC_INIT(ntl-libtool, 1.0) > AM_INIT_AUTOMAKE([foreign]) > AC_CONFIG_FILES([Makefile]) > LT_INIT > AC_PROG_CXX > AC_PROG_CC > AC_PROG_LIBTOOL > AC_OUTPUT > > I don't remember where I got this...but it was from somebody who seemed to > know what they were talking about. > > Maybe the logic of this configure.ac file is not right? > Any thoughts on this? it looks OK, and the libtool you get will ignore -pthread option for gcc/g++, (as this is by design), unless you apply the patch I posted earlier before buiding it. > > > > On Wednesday, August 28, 2019 at 9:55:38 AM UTC-4, vdelecroix wrote: >> >> Victor, as far as I understand the main configuration script of ntl >> is the perl DoConfig script. It has nothing to do with libtool. libtool >> is robust if you let it handle the configuration. It will not try to >> fix a given one. >> >> In a libtool configure.ac script you would just have a directive >> AC_CHECK_LIB for pthread. >> >> In short, I would suggest >> >> 3) Replace DoConfig by a configure.ac script >> >> Vincent >> >> Le 28/08/2019 à 15:15, Victor Shoup a écrit : >> > Thanks. I guess what I'm asking for is a solution. From what you say here, >> > and what is said in the links, the problem seems to be a bug in libtool, >> > not NTL. So a solution would be, either: >> > 1) a patch other type of libtool workaround, or >> > 2) an alternative to libtool. >> > I though the whole point of libtool was to take care of all this nonsense, >> > and if it's not doing that, then >> > it seems kind of pointless. >> > >> > On Tuesday, August 27, 2019 at 1:42:51 PM UTC-4, Antonio Rojas wrote: >> >> >> >> >> >> >> >> El martes, 27 de agosto de 2019, 16:25:12 (UTC+2), Victor Shoup escribió: >> >>> >> >>> I reviewed some comments which mentioned a problem with ntl and threads. >> >>> I’m happy to fix that, but I don’t think I understand what the issue is. >> >>> Can anyone explain? Thanks. >> >> >> >> >> >> Hi Victor, >> >> IIRC I reported this to you about a year ago. The problem is that you >> >> are >> >> using libtool as a build command, which calls the compiler with the >> >> -nostdlib flag, which in turn overrides the -pthread flag, so the binaries >> >> end up not being linked to libpthread. See eg. [1][2] for more info. >> >> >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=661333 >> >> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460 >> >> >> > > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/30264407-95c4-4057-a7a8-5dc0ea8b6437%40googlegroups.com. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq0ovfaJwRSUQNvCPQ6v69St821UW3bcAeQHnfThsGHCdA%40mail.gmail.com.
[sage-devel] Re: Unpickling problem (backwards incompatibility) in Python 3
On Monday, September 2, 2019 at 6:22:24 PM UTC+2, Simon King wrote: > > Also, if I understand the error message "UnicodeDecodeError: 'ascii' > codec can't decode byte 0x80 in position 0: ordinal not in range(128)" > correctly, it is an error in unpickling a string. And this, I believe, > can and must be totally absolutely backwards compatible. > The problem apparently boils down to the following: - Pickle the string '\x80\x1f' in Python-2 - Try to load that pickle in Python-3 (it fails). Bummer! AFAIK, what I need to unpickle my old data is a way to tell Python-3 that it shall (at least temporarily) unpickle all strings as bytes, in the sense that the pickled string '\x80\x1f' should be understood as b'\x80\x1f'. Is there a way? Best regards, SImon -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/c209a82e-b914-4e02-bfae-52130d02c954%40googlegroups.com.
Re: [sage-devel] Re: error building barvinok (sage 8.9.beta8 + system NTL)
OK. So this is really a bug in libtool. It seems to me that even if I used autotools for everything, the same problem would persist without a patch to ltmain.sh. Is that right? On Monday, September 2, 2019 at 4:42:44 PM UTC-4, Dima Pasechnik wrote: > > On Mon, Sep 2, 2019 at 11:37 PM Victor Shoup > wrote: > > > > A clarification and a question... > > > > NTL's config system does not use a pre-built ibtool script. Rather, it > builds a customized libtool by running a configure script on the host > machine, so it should, in principle, be using a libtool script that is > properly configured for the host machine. > > > > The configure script itself was built on a linux machine with up-to-date > autotools using the following configure.ac file: > > > > AC_INIT(ntl-libtool, 1.0) > > AM_INIT_AUTOMAKE([foreign]) > > AC_CONFIG_FILES([Makefile]) > > LT_INIT > > AC_PROG_CXX > > AC_PROG_CC > > AC_PROG_LIBTOOL > > AC_OUTPUT > > > > I don't remember where I got this...but it was from somebody who seemed > to know what they were talking about. > > > > Maybe the logic of this configure.ac file is not right? > > Any thoughts on this? > > it looks OK, and the libtool you get will ignore -pthread option for > gcc/g++, > (as this is by design), unless you apply the patch I posted earlier before > buiding it. > > > > > > > > > > On Wednesday, August 28, 2019 at 9:55:38 AM UTC-4, vdelecroix wrote: > >> > >> Victor, as far as I understand the main configuration script of ntl > >> is the perl DoConfig script. It has nothing to do with libtool. libtool > >> is robust if you let it handle the configuration. It will not try to > >> fix a given one. > >> > >> In a libtool configure.ac script you would just have a directive > >> AC_CHECK_LIB for pthread. > >> > >> In short, I would suggest > >> > >> 3) Replace DoConfig by a configure.ac script > >> > >> Vincent > >> > >> Le 28/08/2019 à 15:15, Victor Shoup a écrit : > >> > Thanks. I guess what I'm asking for is a solution. From what you say > here, > >> > and what is said in the links, the problem seems to be a bug in > libtool, > >> > not NTL. So a solution would be, either: > >> > 1) a patch other type of libtool workaround, or > >> > 2) an alternative to libtool. > >> > I though the whole point of libtool was to take care of all this > nonsense, > >> > and if it's not doing that, then > >> > it seems kind of pointless. > >> > > >> > On Tuesday, August 27, 2019 at 1:42:51 PM UTC-4, Antonio Rojas wrote: > >> >> > >> >> > >> >> > >> >> El martes, 27 de agosto de 2019, 16:25:12 (UTC+2), Victor Shoup > escribió: > >> >>> > >> >>> I reviewed some comments which mentioned a problem with ntl and > threads. > >> >>> I’m happy to fix that, but I don’t think I understand what the > issue is. > >> >>> Can anyone explain? Thanks. > >> >> > >> >> > >> >> Hi Victor, > >> >> IIRC I reported this to you about a year ago. The problem is that > you are > >> >> using libtool as a build command, which calls the compiler with the > >> >> -nostdlib flag, which in turn overrides the -pthread flag, so the > binaries > >> >> end up not being linked to libpthread. See eg. [1][2] for more info. > >> >> > >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=661333 > >> >> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460 > >> >> > >> > > > > > -- > > 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-...@googlegroups.com . > > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/30264407-95c4-4057-a7a8-5dc0ea8b6437%40googlegroups.com. > > > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/77278251-5ad4-42a2-a9f0-c0bf322fb972%40googlegroups.com.
Re: [sage-devel] Re: error building barvinok (sage 8.9.beta8 + system NTL)
On Tue, Sep 3, 2019 at 1:05 AM Victor Shoup wrote: > > OK. So this is really a bug in libtool. it's a feature :-) It's not hard to explicitly pass extra libraries to link to libtool, and thus it's still like this. > It seems to me that even if I used autotools for everything, the same problem > would persist > without a patch to ltmain.sh. > > Is that right? > no, if you use autotools, you'd just add a couple of macros to deal with threads to configure.ac, and the rest will be done correctly, as autotools are aware of this bug/feature of libtool and know what to do. > > On Monday, September 2, 2019 at 4:42:44 PM UTC-4, Dima Pasechnik wrote: >> >> On Mon, Sep 2, 2019 at 11:37 PM Victor Shoup wrote: >> > >> > A clarification and a question... >> > >> > NTL's config system does not use a pre-built ibtool script. Rather, it >> > builds a customized libtool by running a configure script on the host >> > machine, so it should, in principle, be using a libtool script that is >> > properly configured for the host machine. >> > >> > The configure script itself was built on a linux machine with up-to-date >> > autotools using the following configure.ac file: >> > >> > AC_INIT(ntl-libtool, 1.0) >> > AM_INIT_AUTOMAKE([foreign]) >> > AC_CONFIG_FILES([Makefile]) >> > LT_INIT >> > AC_PROG_CXX >> > AC_PROG_CC >> > AC_PROG_LIBTOOL >> > AC_OUTPUT >> > >> > I don't remember where I got this...but it was from somebody who seemed to >> > know what they were talking about. >> > >> > Maybe the logic of this configure.ac file is not right? >> > Any thoughts on this? >> >> it looks OK, and the libtool you get will ignore -pthread option for gcc/g++, >> (as this is by design), unless you apply the patch I posted earlier before >> buiding it. >> >> >> > >> > >> > >> > On Wednesday, August 28, 2019 at 9:55:38 AM UTC-4, vdelecroix wrote: >> >> >> >> Victor, as far as I understand the main configuration script of ntl >> >> is the perl DoConfig script. It has nothing to do with libtool. libtool >> >> is robust if you let it handle the configuration. It will not try to >> >> fix a given one. >> >> >> >> In a libtool configure.ac script you would just have a directive >> >> AC_CHECK_LIB for pthread. >> >> >> >> In short, I would suggest >> >> >> >> 3) Replace DoConfig by a configure.ac script >> >> >> >> Vincent >> >> >> >> Le 28/08/2019 à 15:15, Victor Shoup a écrit : >> >> > Thanks. I guess what I'm asking for is a solution. From what you say >> >> > here, >> >> > and what is said in the links, the problem seems to be a bug in libtool, >> >> > not NTL. So a solution would be, either: >> >> > 1) a patch other type of libtool workaround, or >> >> > 2) an alternative to libtool. >> >> > I though the whole point of libtool was to take care of all this >> >> > nonsense, >> >> > and if it's not doing that, then >> >> > it seems kind of pointless. >> >> > >> >> > On Tuesday, August 27, 2019 at 1:42:51 PM UTC-4, Antonio Rojas wrote: >> >> >> >> >> >> >> >> >> >> >> >> El martes, 27 de agosto de 2019, 16:25:12 (UTC+2), Victor Shoup >> >> >> escribió: >> >> >>> >> >> >>> I reviewed some comments which mentioned a problem with ntl and >> >> >>> threads. >> >> >>> I’m happy to fix that, but I don’t think I understand what the issue >> >> >>> is. >> >> >>> Can anyone explain? Thanks. >> >> >> >> >> >> >> >> >> Hi Victor, >> >> >> IIRC I reported this to you about a year ago. The problem is that >> >> >> you are >> >> >> using libtool as a build command, which calls the compiler with the >> >> >> -nostdlib flag, which in turn overrides the -pthread flag, so the >> >> >> binaries >> >> >> end up not being linked to libpthread. See eg. [1][2] for more info. >> >> >> >> >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=661333 >> >> >> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460 >> >> >> >> >> > >> > >> > -- >> > 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-...@googlegroups.com. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/sage-devel/30264407-95c4-4057-a7a8-5dc0ea8b6437%40googlegroups.com. > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/77278251-5ad4-42a2-a9f0-c0bf322fb972%40googlegroups.com. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq1Bie-zogVmyK4rKBoLycQF9cqnEibvNrJGaophUeoVkA%4
Re: [sage-devel] Re: Unpickling problem (backwards incompatibility) in Python 3
Hi,
Le 02/09/2019 à 22:43, Simon King a écrit :
> AFAIK, what I need to unpickle my old data is a way to tell Python-3
> that it shall (at least temporarily) unpickle all strings as bytes, in
> the sense that the pickled string '\x80\x1f' should be understood as
> b'\x80\x1f'. Is there a way?
I tried to run the following two small scripts, and it didn't complain:
#!/usr/bin/python2
import pickle
s='\x80\x1f'
with open('/tmp/data.pickle', 'w') as handle:
pickle.dump(s, handle, protocol=2)
#!/usr/bin/python3
import pickle
with open('/tmp/data.pickle', 'rb') as handle:
s = pickle.load(handle, encoding='bytes')
I hope that helps,
JP
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/4347937a-bd99-b854-cf90-6bc0bb394358%40laposte.net.
[sage-devel] Re: Unpickling problem (backwards incompatibility) in Python 3
Hi! On 2019-09-02, Simon King wrote: > The problem apparently boils down to the following: > - Pickle the string '\x80\x1f' in Python-2 > - Try to load that pickle in Python-3 (it fails). > > Bummer! Nils Bruin pointed me to https://stackoverflow.com/questions/28218466/unpickling-a-python-2-object-with-python-3 The proposed solution there is to use pickle.load(, encoding='bytes'). The encoding keyword only exist in Python-3. If I undestand correctly (and some basic tests confirm the following statements): - Python-2 can unpickle both pickles created with Python-2 and pickles created with Python-3 can be read with Python-3 - Without `encoding='bytes'`, Python-3 can in general not unpickle any pickle created with Python-2 that contains strings. - With `encoding='bytes'`, Python-3 *can* unpickle a pickle created with Python-2 containing strings, and it doesn't interfere with unpickling a pickle created with Python-3. So, I suggest that at #28444 we change sage.misc.persist so that it uses pickle.load() with the `encoding` keyword in Python-3 and withou that keyword in Python-2. Do the Python-3 experts agree that that approach makes sense? Given that a Python-2 string corresponds to a Python-3 bytes, I think it does, but I am not an expert. Best regards, Simon -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/qkl1dv%247bpp%241%40blaine.gmane.org.
[sage-devel] Re: Unpickling problem (backwards incompatibility) in Python 3
PS: On 2019-09-03, Simon King wrote: > - Without `encoding='bytes'`, Python-3 can in general not unpickle any > pickle created with Python-2 that contains strings. Stated differently: Ostensibly, Python-2 str corresponds to Python-3 bytes, and Python-2 unicode corresponds to Python-3 str. But Python-3 tries to unpickle the pickle of a Python-2 str as a Python-3 str, NOT as a Python-3 bytes. And that's an annoying oddity (or indeed a bug?) in Python, IMHO. Cheers, Simon -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/qkl2ne%24uo5%241%40blaine.gmane.org.
