[sage-devel] Problem with symbolics handling of undefined (formal) functions.

[Emmanuel Charpentier]

This ask.sagemath question 

 led 
me to open Trac#28964 , 
which IMHO is at least critical.

I do not (yet) understand this code...

-- 
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/8be0ce0f-72d7-4efd-bae5-8d84f566e2b0%40googlegroups.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[William]

This is just some clarification and remarks related to what Karl wrote, and 
not really super relevant to this thread...

On Monday, January 6, 2020 at 7:17:16 AM UTC-8, kcrisman wrote:
>
> Because a lot of Sage users are also developers (presumably a higher 
> proportion than for Python or Mathematica!), a lot of Sage work has had 
> developers in mind.  However, I think it is pretty important to pay 
> attention to the users, the vast majority of whom we don't ever hear from, 
> since they aren't paying for Sage.
>
> As an example, if there were a coordinated strategy that a company would 
> make, I can't imagine that there wouldn't have been two versions of Sage 
> cell server going at once - or even an addition (temporary) to the 
> drop-down menu saying "Sage with Python 2", for transitioning.
>

For CoCalc (run by a company), we have many different versions of Sage 
installed for projects to use.  For Jupyter  notebooks, users just 
explicitly select whatever version they want (via kernel selection), and it 
stays selected unless they change it.  For the sage command line, we have a 
"sage_select" command to set the default, or the user can type 
"sage-[version]" to get a specific version.

/ext/bin/sage_select 
Available versions: develop, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 8.8, 8.9, 9.0

For Sage worksheets, they just use whatever is "sage" in the PATH, which is 
a problem since there's a TON of python2 content used on cocalc, much made 
by paying customers (with thousands of students), so we can't break it.  
We've been discussing how to move forward, slowly but surely, here 
https://github.com/sagemathinc/cocalc/issues/4212/. It's a confusing and 
tricky problem because Sage worksheets don't encode the version of Sage 
they use (dumb design decision by me) -- Jupyter is much better in this 
regard.   In any case, we don't have the luxury of break things for our 
paying customers.
 

> I don't know if I want to ask the very capable, but very busy, Andrey N. 
> to do that!  But once again, sage-devel will never know, because the users 
> didn't pay anything, 
>

Users (at least UTMOST) does sometimes pay a little bit to cover some 
hosting (thanks NSF!), but it doesn't cover what Andrey does, and I fully 
support his decision.  I wish I had the money to pay to support maintenance 
of other versions of the Sage cell server, but I don't.
 
William

-- 
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/99d1c833-d393-46b0-a7d3-72e184ba047b%40googlegroups.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[rjf]

just curious when this ends.  Python 4 awaits.  
RJF

On Monday, January 6, 2020 at 10:47:29 AM UTC-8, Nils Bruin wrote:
>
> On Monday, January 6, 2020 at 10:30:23 AM UTC-8, Eric Gourgoulhon wrote:
>>
>>
>> On the other hand, for the end user the major backwards-incompatibility 
>> change already happened: a Python 2-only piece of code will break 
>> immediately in any Sage 9.0 binary. Can we really say to the end user: "to 
>> solve your issue, download SageMath sources and compile them with 
>> ./configure --with-python=2" ?
>>
>
> That's a different issue. If we can't say that, the appropriate fix is to 
> host py2 binaries as well (but hide them a little bit).
>

-- 
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/c372b39f-6232-48a5-bc98-e452c905ab1c%40googlegroups.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[Nils Bruin]

On Monday, January 6, 2020 at 10:30:23 AM UTC-8, Eric Gourgoulhon wrote:
>
>
> On the other hand, for the end user the major backwards-incompatibility 
> change already happened: a Python 2-only piece of code will break 
> immediately in any Sage 9.0 binary. Can we really say to the end user: "to 
> solve your issue, download SageMath sources and compile them with 
> ./configure --with-python=2" ?
>

That's a different issue. If we can't say that, the appropriate fix is to 
host py2 binaries as well (but hide them a little bit).

-- 
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/5063b25b-a348-4b41-8d5f-3a68e3eb8ec5%40googlegroups.com.

[sage-devel] Different behavior in normal usage and when building the doc (decimal separator / tachyon syntax error)

[Jean-Florent Raymond]

Hello,

I have been investigating a bug that happened when I tried to build the
documentation of sage 9.0 on a new machine.
It seems to be the same as described in

https://groups.google.com/d/topic/sage-devel/5jajeJiJNiY/discussion
(the thread describes a way to circumvent it)

In a few words: in order to produce 3d pictures for the documentation,
the script that builds the documentation calls tachyon (because jmol is
not available) and the tachyon call results in a syntax error. Strangely
I have not been able to reproduce this error except when building the
documentation.
The way it works is that a string describing the 3d scene is written to
a temporary file, which is then read by tachyon. Investigating further I
found that some decimal numbers are printed in this file with commas as
decimal separator when building the doc and with dots when running
sage... I highly suspect this to be the reason of the syntax error
raised by tachyon. Below is an example of lines from the two temporary
files corresponding to the same call, the first in normal sage and the
second one obtained when building the doc.

TRI V0 0.641519 0.179487 0.025641 V1 0.641026 0.18109 -0.025641 V2
0.641519 0.179487 -0.025641
TRI V0 0,641519 0,179487 0,025641 V1 0,641026 0,18109 -0,025641 V2
0,641519 0,179487 -0,025641

What I cannot explain is why these lines have been printed differently
(i.e. commas instead of dots). They have been printed by the function
format_tachyon_triangle from src/sage/plot/plot3d/index_face_set.pyx,
whose code is the following (comment is not mine):

cdef inline format_tachyon_triangle(point_c P, point_c Q, point_c R):
cdef char ss[250]
# PyBytes_FromFormat doesn't do floats?
cdef Py_ssize_t r = sprintf_9d(ss,
   "TRI V0 %g %g %g V1 %g %g %g V2 %g %g
%g",
   P.x, P.y, P.z,
   Q.x, Q.y, Q.z,
   R.x, R.y, R.z )
return bytes_to_str(PyBytes_FromStringAndSize(ss, r))

Does anyone here has an idea why this function behaves differently
depending on whether it is called in sage or when building the doc?

Best,
Jean-Florent.

-- 
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/9fcb3ff1-bedb-2a5c-af16-fcee21588e10%40uca.fr.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[Eric Gourgoulhon]

Le lundi 6 janvier 2020 14:21:56 UTC+1, E. Madison Bray a écrit :
>
>
> I agree with Nils.  There should be at least a one release deprecation 
> period.  Also, while I don't think we use any kind of real semantic 
> versioning, I think we should name a Python 3-only release 10.0 as 
> it's a very major backwards-incompatibility change. 
>
>
On the other hand, for the end user the major backwards-incompatibility 
change already happened: a Python 2-only piece of code will break 
immediately in any Sage 9.0 binary. Can we really say to the end user: "to 
solve your issue, download SageMath sources and compile them with 
./configure --with-python=2" ?
As for developers, the Python 3 switch has been discussed for something 
like 2 years, so what would be the point to extend that (effective) 
deprecation period? (maybe I am missing something here)

Eric.

-- 
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/e88ab0aa-63f7-4635-b927-2b04741789c1%40googlegroups.com.

[sage-devel] Re: drop python2 compatibility in 9.1 ?

[Travis Scrimshaw]

I agree that the Python3 only version of Sage should be called 10.0 given 
the large backwards incompatible changes that result from the Python3 
change. Furthermore, I also concur that we should release a version 9.1 (on 
an accelerated schedule) that is our official deprecation version telling 
people they will need to adapt their code in the next version.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/04cbe9fc-0d8f-4e9c-869a-282f3a37961b%40googlegroups.com.

[sage-devel] Re: drop python2 compatibility in 9.1 ?

[Andrey Novoseltsev]

On Monday, 6 January 2020 03:13:02 UTC-7, Frédéric Chapoton wrote:
>
> the wiki promise was written by myself alone, and I think it should be 
> changed. I think there will be very few (or  no) people that will desire to 
> compile sage 9.0 with python 2. And 9.1 even more. People that want to be 
> up to date do not care about py2.
> I therefore strongly vote for the immediate drop of python2, and for 
> removing the promise that 9.1 will be py2-compatible
>

I think that is the most important voice so far. When a single person on 
his own accord made a statement and posted it on a wiki page it should not 
be considered an official and unbreakable promise. When that same person 
wants to pull it back, and for a good reason, why should not we allow this?

We can talk about what would be nice, like running multiple cell servers, 
but let's pay attention to a) what is really happening and b) what are 
people actually willing to do in the future. I am personally not willing to 
work on multiple cell servers - those who really want and have machines 
available can quite easily set up their own server, I have tried hard to 
make it happen a long time ago. Others HAVE to switch to Python 3 sooner or 
later no matter what. Well, that time is now. I've timed the switch as best 
as I could releasing Python 3 version on Christmas and giving those 
preparing for the new term two weeks to adjust. Even with running another 
server some adjustments would be necessary.

Having a deprecation for print statement a year ago would be very useful 
and it was discussed and agreed on - as far as usefulness goes. But nobody 
actually worked on that change, which, I suspect, would be much easier than 
maintaining compatibility with two Pythons now.

I want to reiterate again that I am personally not affected by the decision 
made here in any way. But after years of adjusting SageMathCell to new 
versions of Sage, IPython, and now Python I think I have some idea of 
effort involved for those who do the porting. And I strongly believe that 
efforts of these people are too valuable to be spent on this support.

-- 
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/1c27defa-db0d-4e0e-826a-7b82d620c5b5%40googlegroups.com.

Re: [sage-devel] Adopting orphaned math packages

[E. Madison Bray]

On Mon, Dec 30, 2019 at 9:41 PM Michael Orlitzky  wrote:
>
> On 12/20/19 10:57 AM, E. Madison Bray wrote:
> >
> > I found .spkg archives (which are essentially just zipfiles, or
> > tarballs, I forget which, containing the upstream sources along with
> > some Sage-specific stuff) for 0.3, 0.3.1, and 0.3.2 if you want them.
> > But perhaps it's not even terribly meaningful if they're *that* old
> > and we don't have anything between 0.3.2 and 2.0.
>
> Up to you. I looked in earnest for a copy of v1.0 and wasn't able to
> find one. I'm ready to give up and move forward.
>
> Can you please set things up on gitlab?
>
> The only thing I plan to do immediately is merge the patches that
> everyone is already carrying, and make a v2.0.1 release.

Sorry for the delay; I went ahead and created an empty project under
our organization and added (I assume) you as a maintainer, so have at
it: https://gitlab.com/sagemath/symmetrica

-- 
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/CAOTD34YQgFG4Com6Lj0E31ExvWai5mbTp%2B5rCx%2BUUeD_6S758g%40mail.gmail.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[kcrisman]

On Monday, January 6, 2020 at 8:21:56 AM UTC-5, E. Madison Bray wrote:
>
> On Sun, Jan 5, 2020 at 10:06 PM Nils Bruin > 
> wrote: 
> > 
> > I think our wiki vetoes that idea. See 
> https://wiki.sagemath.org/Python3-Switch : 
> > 
> > Compiling with Python 2 
> > 
> > After version 9.0, if you really want so, you can still build and use 
> SageMath with Python 2, as follows. 
> > 
> > make configure 
> > ./configure --with-python=2 
> > make build 
> > 
> > Beware that you will need to call the second line again if you ever call 
> "make distclean". 
> > 
> > This will work until version 9.1 at least. Then the backward 
> compatibility with Python 2 will no longer be ensured. 
> > 
> > If you want to drop py2 compatibility very soon, the only option is to 
> release 9.1 basically right now, identical to 9.0, and then get on with 
> developing 9.2. That's a nasty thing to do. Based on previous release 
> schedules, people would be justified in expecting that <=9.1 is the 
> "current" release until at least June 2020 or so. So we're stuck with py2 
> compatibility until that time. 
>
> I agree with Nils.  There should be at least a one release deprecation 
> period.  Also, while I don't think we use any kind of real semantic 
> versioning, I think we should name a Python 3-only release 10.0 as 
> it's a very major backwards-incompatibility change. 
>
> Instead for 9.1 let us display a prominent deprecation message in any 
> Python 2 builds when running Sage, including a link to a guide for 
> porting existing code (for Sage there is not all that much to 
> do--mostly any generic Python 2 to 3 porting guide will do, plus some 
> Sage-specific caveats of which I can't think of many). 
>


Because a lot of Sage users are also developers (presumably a higher 
proportion than for Python or Mathematica!), a lot of Sage work has had 
developers in mind.  However, I think it is pretty important to pay 
attention to the users, the vast majority of whom we don't ever hear from, 
since they aren't paying for Sage.

As an example, if there were a coordinated strategy that a company would 
make, I can't imagine that there wouldn't have been two versions of Sage 
cell server going at once - or even an addition (temporary) to the 
drop-down menu saying "Sage with Python 2", for transitioning. I don't know 
if I want to ask the very capable, but very busy, Andrey N. to do that! 
 But once again, sage-devel will never know, because the users didn't pay 
anything, so they may just decide to drop it.  I know it's a headache for 
any authors using PreTeXt who used "print" statements, because it's not 
just changing your own code, but releasing a new version of a book. 
 Presumably many many worksheets (sagenb or Jupyter) also are in the same 
boat - and one can say "oh, there was time" but we all know that many Sage 
users do not actually upgrade very frequently, because Sage is so usable 
and stable in the core functionality, so they may not have been at all 
aware of the necessity.  They just know their code is breaking.

This doesn't mean we shouldn't have switched to Py3 or Jupyter or whatever 
the backwards-incompatible flavor of the month is - that much is clear. 
 But the only way the community grows is by attracting people long enough 
to have a certain percentage become developers, and that does mean some 
boring "customer service" for our volunteer force.  I would call the work 
done at ask.sagemath.org and pretextbook.org actually very valuable in 
these terms, even if little of it goes directly toward developing new 
capabilities in Sage.  (CoCalc also performs a lot of this customer base 
development/service but since it is at least partly non-volunteer I put it 
in a different category.)

I think the easiest way out of this whole business actually is to have a 
relatively small bugfix 9.1 changeset, with OFFICIAL BINARIES in Python 2 
posted, and those left up indefinitely, clearly marked as "Python 2".   
(Having a choice of Sage cell server as well for some indeterminate period 
would be good, but again it is a lot to presume on Andrey alone for that.) 
 Does anyone know whether it is easy to use binary-pkg to create Python 2 
binaries - it is as simple as adding a line in the sage.yaml file, or would 
one have to do something on the command line e.g. an env var first?

- kcrisman

-- 
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/4293103a-5f9b-434c-a67a-8cf4aa257797%40googlegroups.com.

Re: [sage-devel] Graph Coloring and Gröbner Bases.

[E. Madison Bray]

On Thu, Jan 2, 2020 at 2:01 PM Oktay Cesur  wrote:
>
> Hello Everyone.
>
> I'm a master student and I'm a beginner in a sage. I learned sage for 
> symbolic computation course one month ago. I did a presentation about graph 
> coloring problem solving with gröbner bases. Main source is this. Now I'm 
> preparing a report. When I preparing my presentation, I realized graph 
> coloring ideals is used very often for gröbner bases an application. But I 
> couldn't find a ready code for it and I wrote the code for this.
> I think, some of my code can be added to sage. I've reviewed the developer 
> guide but it's so long and I have to finish my report until 5 January. Is 
> there anything I can do before I delivery the report? If it is possible, I 
> would like to include it in the report. If it's not, I will focus on my 
> report and final exams. In both cases, I will do an in-depth study for my 
> purpose after exams. I know my goal will take long. I'm just wondering if 
> there's anything I can do in this short time.
> I'll be happy if you can help me.

If you think your code will make a valuable addition directly to Sage
(and others with knowledge of the relevant area agree) you could
certainly open a ticket to propose an enhancement.  However, if you
just wrote some code using Sage but that does not need to modify any
of the Sage sources directly, you can always distribute your code as a
separate package that depends on Sage.  E.g. by following
https://github.com/sagemath/sage-package

But it's not exactly clear what you need/want to do.  Where is your code?

-- 
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/CAOTD34Z_-H7Ewh1F8uJ3kvMkYgpGAmSzc6x-wS8d3MWK0TGbvA%40mail.gmail.com.

Re: [sage-devel] Building sage-9.0 fails on Cygwin64 with fflas-ffpack errors

[Darij Grinberg]

On Mon, Jan 6, 2020 at 3:06 PM E. Madison Bray  wrote:
> Yep. You can also get around it without modifying *any* files by
> building Sage with:
>
> FFLAS_FFPACK_CONFIGURE=--disable-openmp

Thanks; this removes the need to mess with the repository.

> I do think someone should look into this more.  I don't know exactly
> why it happens: Why does fflas-ffpack try to build with OpenMP support
> if OpenMP support isn't actually working in the first place?  Does it
> not check?  Furthermore, it would be nice to see if you *can* get it
> working with OMP on Cygwin; I just haven't tried using OMP on Cygwin
> yet, though I believe it can work...

Afraid I won't be of much use with this... (Quite possibly my Cygwin
isn't very up-to-date either.)

  Best regards,
  Darij

-- 
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/CAN3jM_kKYR3AphGb2ZVGzjzFiaSTEp%2B328_vW363N-1OqQLYOQ%40mail.gmail.com.

Re: [sage-devel] Building sage-9.0 fails on Cygwin64 with fflas-ffpack errors

[E. Madison Bray]

On Sun, Jan 5, 2020 at 6:22 PM Darij Grinberg  wrote:
>
> Aha. The build failure was caused by
> https://trac.sagemath.org/ticket/27444 , exactly as embray's
> comment:34 suggested. Undoing the 1-line change from that branch to
> build/pkgs/fflas_ffpack/spkg-install and recompiling fflas_ffpack
> (sage -f fflas_ffpack) got me through that point. Hope the rest of the
> build goes smoothly... --Darij

Yep. You can also get around it without modifying *any* files by
building Sage with:

FFLAS_FFPACK_CONFIGURE=--disable-openmp

I do think someone should look into this more.  I don't know exactly
why it happens: Why does fflas-ffpack try to build with OpenMP support
if OpenMP support isn't actually working in the first place?  Does it
not check?  Furthermore, it would be nice to see if you *can* get it
working with OMP on Cygwin; I just haven't tried using OMP on Cygwin
yet, though I believe it can work...


> On Fri, Jan 3, 2020 at 5:13 PM Darij Grinberg  wrote:
> >
> > From the end of install.log:
> >
> > build/temp.cygwin-3.0.7-x86_64-3.7/build/cythonized/sage/matrix/matrix_modn_sparse.o:
> >  In function `FFPACK::rns_double::reduce(unsigned long, double*, unsigned 
> > long, bool) const':
> > [sagelib-9.0] 
> > /home/skraeling/sage/local/include/fflas-ffpack/field/rns-double.inl:530: 
> > undefined reference to `omp_get_num_threads'
> > [sagelib-9.0] 
> > /home/skraeling/sage/local/include/fflas-ffpack/field/rns-double.inl:533: 
> > undefined reference to `GOMP_parallel'
> > [sagelib-9.0] 
> > build/temp.cygwin-3.0.7-x86_64-3.7/build/cythonized/sage/matrix/matrix_modn_sparse.o:
> >  In function `FFPACK::rns_double::init(unsigned long, unsigned long, 
> > double*, unsigned long, Givaro::Integer const*, unsigned long, unsigned 
> > long, bool) const':
> > [sagelib-9.0] 
> > /home/skraeling/sage/local/include/fflas-ffpack/paladin/blockcuts.inl:67: 
> > undefined reference to `omp_get_num_threads'
> > [sagelib-9.0] collect2: error: ld returned 1 exit status
> > [sagelib-9.0] error: command 'g++' failed with exit status 1
> > [sagelib-9.0] make[4]: *** [Makefile:33: sage] Error 1
> > [sagelib-9.0] make[4]: Leaving directory '/home/skraeling/sage/src'
> >
> > This happens reproducibly both with "make" and with "make install", after 
> > the sagelib modules compile. There are further "undefined reference" 
> > messages all the way during the sagelib compilation process.
> >
> > Any ideas?
> >
> > Best regards & happy almost-new year,
> > Darij
> >
> > --
> > You received this message because you are subscribed to a topic in the 
> > Google Groups "sage-devel" group.
> > To unsubscribe from this topic, visit 
> > https://groups.google.com/d/topic/sage-devel/O06i87XYpz8/unsubscribe.
> > To unsubscribe from this group and all its topics, 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/e3b50139-609f-4a06-bed5-2bc65ed89b35%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/CAN3jM_nWAK7Ccb3bVR-xWpOZ6A_TcL8tsz1r0Zzx7y%2BA0VH2hQ%40mail.gmail.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/CAOTD34aoP2Cf-wdfWy5WfNw_Y1Gj07jYnA7J9dN8Uj6VoUGjLw%40mail.gmail.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[E. Madison Bray]

On Sun, Jan 5, 2020 at 10:06 PM Nils Bruin  wrote:
>
> I think our wiki vetoes that idea. See 
> https://wiki.sagemath.org/Python3-Switch :
>
> Compiling with Python 2
>
> After version 9.0, if you really want so, you can still build and use 
> SageMath with Python 2, as follows.
>
> make configure
> ./configure --with-python=2
> make build
>
> Beware that you will need to call the second line again if you ever call 
> "make distclean".
>
> This will work until version 9.1 at least. Then the backward compatibility 
> with Python 2 will no longer be ensured.
>
> If you want to drop py2 compatibility very soon, the only option is to 
> release 9.1 basically right now, identical to 9.0, and then get on with 
> developing 9.2. That's a nasty thing to do. Based on previous release 
> schedules, people would be justified in expecting that <=9.1 is the "current" 
> release until at least June 2020 or so. So we're stuck with py2 compatibility 
> until that time.

I agree with Nils.  There should be at least a one release deprecation
period.  Also, while I don't think we use any kind of real semantic
versioning, I think we should name a Python 3-only release 10.0 as
it's a very major backwards-incompatibility change.

Instead for 9.1 let us display a prominent deprecation message in any
Python 2 builds when running Sage, including a link to a guide for
porting existing code (for Sage there is not all that much to
do--mostly any generic Python 2 to 3 porting guide will do, plus some
Sage-specific caveats of which I can't think of many).

-- 
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/CAOTD34aWri4C-U4XqGHcO77UB6%2BNgAvvbofBtxfuWkgU4UGR4w%40mail.gmail.com.

[sage-devel] Re: drop python2 compatibility in 9.1 ?

[Simon King]

Hi Nils,

On 2020-01-06, Nils Bruin  wrote:
> In fact, I think it would make a lot of sense to make 9.1 the last release 
> to support py2 and therefore make 9.1 more a bugfix release: concentrate on 
> fixes of issues that arise as a result of 9.0 and fix them, so that there's 
> a relatively reliable point in the history of sage to run on py2. That 
> would automatically target significant new features for 9.2.

Having a bugfix release as the last py-2-supporting release sounds like
a good plan to me. So, +1 to this.

Also I think that the additional burden to average developers will be
small: If (on top of bug fixes) there would be new code in v9.1, then
making it work with py-2 would basically involve some "from __future__
import", isn't it?

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/quv67d%2478qv%241%40blaine.gmane.org.

[sage-devel] Re: drop python2 compatibility in 9.1 ?

[Frédéric Chapoton]

the wiki promise was written by myself alone, and I think it should be 
changed. I think there will be very few (or  no) people that will desire to 
compile sage 9.0 with python 2. And 9.1 even more. People that want to be 
up to date do not care about py2.
I therefore strongly vote for the immediate drop of python2, and for 
removing the promise that 9.1 will be py2-compatible

F

Le dimanche 5 janvier 2020 22:06:21 UTC+1, Nils Bruin a écrit :
>
> I think our wiki vetoes that idea. See 
> https://wiki.sagemath.org/Python3-Switch :
>
> Compiling with Python 2 
>
> After version 9.0, if you really want so, you can still build and use 
> SageMath with *Python 2*, as follows. 
>
> make configure./configure --with-python=2make build
>
> Beware that you will need to call the second line again if you ever call 
> "make distclean". 
> This will work until version 9.1 at least. Then the backward compatibility 
> with Python 2 will no longer be ensured. 
>
> If you want to drop py2 compatibility very soon, the only option is to 
> release 9.1 basically right now, identical to 9.0, and then get on with 
> developing 9.2. That's a nasty thing to do. Based on previous release 
> schedules, people would be justified in expecting that <=9.1 is the 
> "current" release until at least June 2020 or so. So we're stuck with py2 
> compatibility until that time.
>

-- 
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/11341de1-238b-4abe-b617-e328af87b639%40googlegroups.com.

[sage-devel] Re: drop python2 compatibility in 9.1 ?

[Antonio Rojas]

El lunes, 6 de enero de 2020, 8:43:14 (UTC+1), Nils Bruin escribió:
>
>
> You could say: there is such a way: just check out 9.0 and build that with 
> py2. Perhaps that's enough. However, I would err at the side of caution and 
> make a slightly bigger gesture here and still include 9.1 as well -- that 
> was published as a definite promise already. Once again, for any piece of 
> code where this turns out to be a bother, just wait with the merge until 
> 9.2. I don't think it needs to put a very large load on developers. It will 
> mainly be a pain for the release manager, so he/she should actually get to 
> have a significant voice in this
>

It's not as simple as waiting for 9.2 to merge them. Some of the pending 
changes (ipython 7 and python 3.8 support) require huge patches that touch 
lots of files. This means that they will probably need rebasing for every 
single beta release (this has been the case until now), which makes it not 
really practical to start working on them on trac until the 9.2 cycle 
starts. Until then the burden of maintaining the patches falls on the 
downstream packagers - and the situation is only going to get worse as new 
python3-only versions of dependencies are released and updated on distros. 

>  
>

-- 
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/e1ad7cf6-e2c6-482e-83d2-c2992d725efd%40googlegroups.com.