Re: [sage-devel] Adopting orphaned math packages

[Michael Orlitzky]

We wound up targeting symmetrica-3.0.0 now, since it turns out every
distro had moved the public def.h and macro.h headers, and that's a
breaking change if we adopt it upstream. My personal TODO list is mostly
done. I'm going to add some more stuff to the README, but probably won't
make any more code changes before v3 unless someone points out an issue.


On 1/9/20 6:27 AM, E. Madison Bray wrote:
> 
> Great, I'll give it a try.  It's nice they were able to help you add a
> proper autoconf-based build system.  I'm going to test it out on
> Cygwin.

I'll wait to hear if this worked first, though. There are some questions
about Windows support in issues #2 and #6 that I think I've answered,
but who knows.


> Maybe said Debian maintainer can help me out on my automake rework of
> zn_poly's build system:

That's another one that I'd be afraid to add to Gentoo in its current
state, so I'm sure you'll hear from me eventually.

-- 
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/ad64bb75-d98f-f783-b8be-58beea4b1481%40orlitzky.com.

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

[Nathan Dunfield]

On Friday, January 10, 2020 at 8:11:43 AM UTC-8, William wrote:
>
> The main person that has valid reason to want longer support for python2 
>> is William.
>> As he mentions, he has paying customers.
>>
>
> I am 100% satisfied for my use case with cocalc by just keeping a copy of 
> sage-8.9 available longterm.   Fortunately, I don't need any sage-9.x 
> versions to support python2.
>

I think that for nearly all users, in practice sage < 9.0 will mean Python 
2 and sage >= 9.0 will mean Python 3.  There will be a handful of folks who 
use (sage-9.x + Python 2) for whatever few values of x this will work for, 
but I agree with William and others that in nearly all cases just using 8.9 
would suffice.

Given that the period of official dual Python 2/Python 3 support is going 
to be a few months, not years, I see no harm in removing Python 2 support 
in Sage 9.1.

In terms of helping users with thousands of lines of Python 2 based Sage 
code, trying to keep building Sage 8.9-the-distribution binaries for future 
OS releases as they come out is probably a lot more effective than working 
hard to push back the date that Python 2 support is dropped from Sage 9.x.

Best,

Nathan


-- 
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/45548347-5167-43e1-a50e-6120e98a83d2%40googlegroups.com.

Re: [sage-devel] optional tag for sage versions (doctest)

[Michael Orlitzky]

On 1/10/20 2:16 PM, Vincent Delecroix wrote:
> 
> - Any alternative suggestion?

This comes up a lot. The ideal answer is: use a preprocessor directive
to compile out the unsupported tests. But naturally that doesn't work so
well in an interpreted language.

One workaround is to maintain separate branches of your code, for
example a 1.x branch that supports sage < 9.0, and a 2.x branch that
supports sage >= 9.0. So long as the number of distinct version ranges
you support is small, this isn't *too* annoying.


> - Any vote pro or against such a tag? I think that if we go
>for it, everybody should agree so that it becomes a standard
>and gets specified in the SageMath documentation.
> 
> Of course such a tag would be useless for the Sage library itself.
> 

All the other solutions I'm aware of involve runtime testing of some
kind. Even if you detect the sage version at "build time," you wind up
with a runtime variable test like

  if sage_version >= 9.0:
  some_function.__doc__ += "a test for sage-9.x"

And that's more or less what the "# optional" tag gives you anyway.

Since the doctests are supposed to serve foremost as documentation, my
first impression is that a dedicated tag would be appropriate here. It's
consistent with what we already do, and it helps the reader understand
what's going on without making the source code horrendous.


-- 
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/ba1349a2-3e0c-8655-24ba-b0189db0f21d%40orlitzky.com.

Re: [sage-devel] optional tag for sage versions (doctest)

[David Roe]

On Fri, Jan 10, 2020 at 1:16 PM Vincent Delecroix <20100.delecr...@gmail.com>
wrote:

> Dear all,
>
> I do maintain Python libraries that depend on Sage and uses the
> Sage doctest framework. I do my best so that the libraries
> install and work on older versions of Sage. However, some features
> are only working with recent enough versions of Sage. But I still
> want them to pass the test suite with older Sage versions.
>
> I thought that having a tag looking like
>
>sage: my_computation()   # optional: sage >= 9.0
>
> would help me a lot.
>
> - Any alternative suggestion?
>
> - Can I do that with the current doctest framework? It would
>be nice to be able to specify optional tags on the fly.
>

I'm not sure what you mean by "on the fly".  For the relevant code, see the
`parse_optional_tags` function in sage/doctest/parsing.py and the parse
method of SageDocTestParser in the same file.
David


> - Any vote pro or against such a tag? I think that if we go
>for it, everybody should agree so that it becomes a standard
>and gets specified in the SageMath documentation.


> Of course such a tag would be useless for the Sage library itself.
>
> Best
> Vincent
>
> --
> 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/103a321e-6c58-f8cc-a1e3-cf1e426ec551%40gmail.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/CAChs6_%3DNGE6rNvsJGwSEF%3Dr4FYPmAQwAkjrsjvpnkQBvg2psQQ%40mail.gmail.com.

[sage-devel] optional tag for sage versions (doctest)

[Vincent Delecroix]

Dear all,

I do maintain Python libraries that depend on Sage and uses the
Sage doctest framework. I do my best so that the libraries
install and work on older versions of Sage. However, some features
are only working with recent enough versions of Sage. But I still
want them to pass the test suite with older Sage versions.

I thought that having a tag looking like

  sage: my_computation()   # optional: sage >= 9.0

would help me a lot.

- Any alternative suggestion?

- Can I do that with the current doctest framework? It would
  be nice to be able to specify optional tags on the fly.

- Any vote pro or against such a tag? I think that if we go
  for it, everybody should agree so that it becomes a standard
  and gets specified in the SageMath documentation.

Of course such a tag would be useless for the Sage library itself.

Best
Vincent

--
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/103a321e-6c58-f8cc-a1e3-cf1e426ec551%40gmail.com.

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

[William Stein]

> The main person that has valid reason to want longer support for python2
> is William.
> As he mentions, he has paying customers.
>

I am 100% satisfied for my use case with cocalc by just keeping a copy of
sage-8.9 available longterm.   Fortunately, I don't need any sage-9.x
versions to support python2.



> At this point my only reasonable suggestion is to have a python2
> compatibility branch
> for a while as sage-9.x while some of us plow on ahead without in
> sage-10.x.
> That’s unreasonable on the release manager unless someone step up to help.
>
> François
>
> --
> 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/vYlbnAwKATM/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/BBC8CF32-2E9D-4DC0-BBE5-5130E15B3B14%40gmail.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/CACLE5GC5ep%2BM%2BUSu%2BDK%2BY7SeGj3%3D4OD1f%3DSLXH8Et9vsAAFC%3Dg%40mail.gmail.com.

[sage-devel] Re: Porting .sage files to sage-9.0

[kcrisman]

On Thursday, January 9, 2020 at 6:45:50 PM UTC-5, David Roe wrote:
>
> I had a recent discussion asking if there are any good tools for porting 
> Sage code to Python 3.  Given the recent discussion 
>  about 
> how long we support Python 2, it seems like one concrete step we can take 
> to help users is to provide some documentation for doing so.
>
> The first step would seem to be to update our FAQ 
> 
>  to 
> reflect the current status (and probably the outcome of the discussion 
> about how long we support Python 2), with a pointer to the relevant 
>  wiki 
>  pages 
> .  But I don't see any discussion 
> on those pages about using any of the tools for porting from Python 2 to 
> Python 3 on .sage files.  Has anyone tried this yet?  
>

I've been doing a set of files by hand, and think it would be helpful for 
there to be info on where to look for guidance on some of the more subtle 
porting issues beyond print statements.  Two examples I hit just now:
* Any backslash LaTeX in strings intended for consumption elsewhere in Sage 
(via printing or MathJax, presumably) needs to be in a raw string, 
apparently.  E.g. r"$5\equiv 2 (\text{mod }3)$" whereas before "$5\equiv 2 
(\\text{mod }3)$" worked.
* I had one usage of "map" which was wrong from a Python 3 point of view in 
the two ways not mentioned in the usual guides, e.g. 
see 
https://stackoverflow.com/questions/12015521/python-3-vs-python-2-map-behavior

So this would be a good service to provide, as well as what can't be 
handled automatically with ease.  Also note that such porting tools might 
possibly gag on some Sage non-Python syntax, e.g. f(x)=x^2 ?  Just guessing 
there.

-- 
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/bbb6a793-8396-4a23-ac3d-6eea14045514%40googlegroups.com.

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

[Vincent Delecroix]

Le 10/01/2020 à 14:54, E. Madison Bray a écrit :

On Fri, Jan 10, 2020 at 11:49 AM Isuru Fernando  wrote:



On Fri, Jan 10, 2020 at 3:53 PM E. Madison Bray  wrote:


On Fri, Jan 10, 2020 at 10:41 AM Timo Kaufmann  wrote:


I have said this before, but I feel like the point was dropped out of the discussion so 
I'll stress it again. The major issue here is *not* the compatibility of sage's own 
codebase. A few "from __future__ import"'s are not so bad.

The issue is that python2 compatibility forces us to use outdated versions of a 
lot of libraries, since many libraries have dropped python2 support a while 
ago. This is a big headache especially for packagers. Those outdated libraries 
are generally not available on distros. At the same time sage is usually not 
compatible with the newer versions. Sage is already difficult to package, and 
that makes it a lot more difficult.


Can you be more specific about this?  What is it about Sage's upstream
codebase maintaining backwards-compatibility for Python 2 that
prevents you from packaging it for Python 3 only, given that it does
support Python 3?  No one is saying that just because upstream support
is maintained for Python 2 for one or two (at the most) more releases,
any downstream packagers have to package it for Python 2.



I'll give an example. sage has rpy2 2.8.2.
rpy2 latest is 3.2.4 but 3.x series is python 3 only and sage requires breaking 
changes to support rpy2 3.x. See 
https://trac.sagemath.org/ticket/28494#comment:6
While python2 support for rpy2 is required, sage codebase can't be updated to 
3.x (unless someone adds code to detect rpy2 version and support both 2.8.2 and 
3.2.4)


That seems like the obvious approach to me.  As it is I've long felt
that Sage should be more flexible in its dependencies where
possible/necessary.  With most Python packages it's easy as most have
a .__version__ and its not so hard to define some variable
like IS_RPY_2 and just have two separate branches.  I have things like
that all over the place in other packages to support e.g. different
Numpy versions or work around version-specific bugs.



+1. I also do that with many Python packages that I develop and depend
on Sage. This is the only way I found to support multiple Sage versions.

--
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/5f87ae84-023d-4cbf-e8fc-75f894ee543a%40gmail.com.

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

[E. Madison Bray]

On Fri, Jan 10, 2020 at 11:49 AM Isuru Fernando  wrote:
>
>
> On Fri, Jan 10, 2020 at 3:53 PM E. Madison Bray  wrote:
>>
>> On Fri, Jan 10, 2020 at 10:41 AM Timo Kaufmann  wrote:
>> >
>> > I have said this before, but I feel like the point was dropped out of the 
>> > discussion so I'll stress it again. The major issue here is *not* the 
>> > compatibility of sage's own codebase. A few "from __future__ import"'s are 
>> > not so bad.
>> >
>> > The issue is that python2 compatibility forces us to use outdated versions 
>> > of a lot of libraries, since many libraries have dropped python2 support a 
>> > while ago. This is a big headache especially for packagers. Those outdated 
>> > libraries are generally not available on distros. At the same time sage is 
>> > usually not compatible with the newer versions. Sage is already difficult 
>> > to package, and that makes it a lot more difficult.
>>
>> Can you be more specific about this?  What is it about Sage's upstream
>> codebase maintaining backwards-compatibility for Python 2 that
>> prevents you from packaging it for Python 3 only, given that it does
>> support Python 3?  No one is saying that just because upstream support
>> is maintained for Python 2 for one or two (at the most) more releases,
>> any downstream packagers have to package it for Python 2.
>
>
> I'll give an example. sage has rpy2 2.8.2.
> rpy2 latest is 3.2.4 but 3.x series is python 3 only and sage requires 
> breaking changes to support rpy2 3.x. See 
> https://trac.sagemath.org/ticket/28494#comment:6
> While python2 support for rpy2 is required, sage codebase can't be updated to 
> 3.x (unless someone adds code to detect rpy2 version and support both 2.8.2 
> and 3.2.4)

That seems like the obvious approach to me.  As it is I've long felt
that Sage should be more flexible in its dependencies where
possible/necessary.  With most Python packages it's easy as most have
a .__version__ and its not so hard to define some variable
like IS_RPY_2 and just have two separate branches.  I have things like
that all over the place in other packages to support e.g. different
Numpy versions or work around version-specific bugs.

-- 
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/CAOTD34a9wVPCu7LPcH_onCvCaViY70dSUH-DJxR1M5PbHYS%2BFQ%40mail.gmail.com.

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

[Isuru Fernando]

On Fri, Jan 10, 2020 at 3:53 PM E. Madison Bray 
wrote:

> On Fri, Jan 10, 2020 at 10:41 AM Timo Kaufmann 
> wrote:
> >
> > I have said this before, but I feel like the point was dropped out of
> the discussion so I'll stress it again. The major issue here is *not* the
> compatibility of sage's own codebase. A few "from __future__ import"'s are
> not so bad.
> >
> > The issue is that python2 compatibility forces us to use outdated
> versions of a lot of libraries, since many libraries have dropped python2
> support a while ago. This is a big headache especially for packagers. Those
> outdated libraries are generally not available on distros. At the same time
> sage is usually not compatible with the newer versions. Sage is already
> difficult to package, and that makes it a lot more difficult.
>
> Can you be more specific about this?  What is it about Sage's upstream
> codebase maintaining backwards-compatibility for Python 2 that
> prevents you from packaging it for Python 3 only, given that it does
> support Python 3?  No one is saying that just because upstream support
> is maintained for Python 2 for one or two (at the most) more releases,
> any downstream packagers have to package it for Python 2.
>

I'll give an example. sage has rpy2 2.8.2.
rpy2 latest is 3.2.4 but 3.x series is python 3 only and sage requires
breaking changes to support rpy2 3.x. See
https://trac.sagemath.org/ticket/28494#comment:6
While python2 support for rpy2 is required, sage codebase can't be updated
to 3.x (unless someone adds code to detect rpy2 version and support both
2.8.2 and 3.2.4)

Isuru


> --
> 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/CAOTD34ZqHf%2BrzoSD8juhhk%3D4YF1WB6BHZuxAOO0ZQYk6KhhX_g%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/CA%2B01voMi8UybPwJMB_dq9RfeULarnQ_pWrXj09Fxbc%3D2_kiviA%40mail.gmail.com.

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

[Vincent Delecroix]

Le 06/01/2020 à 00:24, Nils Bruin a écrit :

On Sunday, January 5, 2020 at 2:51:44 PM UTC-8, Nils Bruin wrote:


I don't think there's a doubt that we'll drop py2.7 support. This Wiki,
however, has been referred to in many places describing the py2/py3
transition.



One of these places is the FAQ, which is official documentation:

http://doc.sagemath.org/html/en/faq/faq-usage.html#can-i-use-sagemath-with-python-3-x

The 9.0 FAQ still mentions:

As of August 2019, most of SageMath works fine with Python 3. However, we
still consider Python 3 support to be experimental and no official Python 3
release has been made yet.

That would probably be good to adjust too: there is now an official Py3
release and I don't think we consider it experimental anymore -- unless
sage in its entirety is still considered experimental :-).



See https://trac.sagemath.org/ticket/28980 (even though Frédéric claims
that it might have been done in another ticket).

--
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/126b6e30-8f93-333e-a436-2ae5015a0dcd%40gmail.com.

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

[François Bissey]

> On 10/01/2020, at 11:23 PM, E. Madison Bray  wrote:
> 
> On Fri, Jan 10, 2020 at 10:41 AM Timo Kaufmann  wrote:
>> 
>> I have said this before, but I feel like the point was dropped out of the 
>> discussion so I'll stress it again. The major issue here is *not* the 
>> compatibility of sage's own codebase. A few "from __future__ import"'s are 
>> not so bad.
>> 
>> The issue is that python2 compatibility forces us to use outdated versions 
>> of a lot of libraries, since many libraries have dropped python2 support a 
>> while ago. This is a big headache especially for packagers. Those outdated 
>> libraries are generally not available on distros. At the same time sage is 
>> usually not compatible with the newer versions. Sage is already difficult to 
>> package, and that makes it a lot more difficult.
> 
> Can you be more specific about this?  What is it about Sage's upstream
> codebase maintaining backwards-compatibility for Python 2 that
> prevents you from packaging it for Python 3 only, given that it does
> support Python 3?  No one is saying that just because upstream support
> is maintained for Python 2 for one or two (at the most) more releases,
> any downstream packagers have to package it for Python 2.

We don’t. I only support python3 anymore on gentoo - because support for python2
ipython/jupyter as been removed from the main tree.
I am the lucky one because I still have an ipython-5 I can pull as a dependency,
most of my colleagues have to go ipython-7+ which is python3 only and requires
heavy patching. Some interesting packages we may want to use that are python3 
only
and that will make our life difficult because we have to move forward regardless
* ipython-7
* matplotlib-3
* sphinx-2
* numpy-1.17
* scipy-1.3+
 
The main person that has valid reason to want longer support for python2 is 
William.
As he mentions, he has paying customers.

At this point my only reasonable suggestion is to have a python2 compatibility 
branch
for a while as sage-9.x while some of us plow on ahead without in sage-10.x.
That’s unreasonable on the release manager unless someone step up to help.

François 

-- 
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/BBC8CF32-2E9D-4DC0-BBE5-5130E15B3B14%40gmail.com.

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

[E. Madison Bray]

On Fri, Jan 10, 2020 at 10:41 AM Timo Kaufmann  wrote:
>
> I have said this before, but I feel like the point was dropped out of the 
> discussion so I'll stress it again. The major issue here is *not* the 
> compatibility of sage's own codebase. A few "from __future__ import"'s are 
> not so bad.
>
> The issue is that python2 compatibility forces us to use outdated versions of 
> a lot of libraries, since many libraries have dropped python2 support a while 
> ago. This is a big headache especially for packagers. Those outdated 
> libraries are generally not available on distros. At the same time sage is 
> usually not compatible with the newer versions. Sage is already difficult to 
> package, and that makes it a lot more difficult.

Can you be more specific about this?  What is it about Sage's upstream
codebase maintaining backwards-compatibility for Python 2 that
prevents you from packaging it for Python 3 only, given that it does
support Python 3?  No one is saying that just because upstream support
is maintained for Python 2 for one or two (at the most) more releases,
any downstream packagers have to package it for Python 2.

-- 
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/CAOTD34ZqHf%2BrzoSD8juhhk%3D4YF1WB6BHZuxAOO0ZQYk6KhhX_g%40mail.gmail.com.

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

[Timo Kaufmann]

I have said this before, but I feel like the point was dropped out of the 
discussion so I'll stress it again. The major issue here is *not* the 
compatibility of sage's own codebase. A few "from __future__ import"'s are 
not so bad.

The issue is that python2 compatibility forces us to use outdated versions 
of a lot of libraries, since many libraries have dropped python2 support a 
while ago. This is a big headache especially for packagers. Those outdated 
libraries are generally not available on distros. At the same time sage is 
usually not compatible with the newer versions. Sage is already difficult 
to package, and that makes it a lot more difficult.

Case in point, my own efforts to update sage on nixos to 9.0 and python3 
have been blocked by incompatibilities in a new sphinx version 
(https://trac.sagemath.org/ticket/28856). I have already put some hours 
into this, but I simply don't have time to maintain a sage package if all 
the compatibility efforts fall to packagers. Another example is Antonio's 
multiple thousand line patch he mentioned earlier.

The alternatives are:

(1) create infrastructure in sage that allows us to use newer dependencies 
in python3 (https://trac.sagemath.org/ticket/28190), and make sage 
compatible with both the py2 and py3 version. This is a lot of effort.

(2) drop python2 support ASAP, e.g. in 9.1, and make sage compatible with 
the newer libraries

(3) continue as-is and leave it to packers to "deal with it"

As I said, (1) is a lot of effort. It would be the nicest solution, but I 
don't think there are enough people willing to do the work quickly enough. 
Especially if that effort will be wasted in a couple of months' time once 
py2 support is dropped.

(2) is my favorite solution. It re-synchronizes upstream with downstream 
distributions (which will most likely no longer package the python2 version 
anyways). I see very little downsides to this. Yes, some people will need 
longer to switch over their codebases. But their existing codebases, having 
been written before 9.1, will work with sage 9.0. So why not continue using 
it as long as the porting efforts take?

And again, I think (3) is a very bad solution. Sage already takes many 
times the packaging effort than most other packages. If this effort 
increases, I won't be willing or able to keep it up.

Sorry for the rant, I hope the email didn't get too long for people to 
read. 

-- 
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/288c5857-c4ae-43e9-8d0d-bb67319e470f%40googlegroups.com.

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

[E. Madison Bray]

On Fri, Jan 10, 2020 at 1:03 AM Volker Braun  wrote:
>
> * I think its not too difficult to write code that is Python 2.7 + 3.x (for 
> high enough x) compatible, so its not a super pressing issue
> * We do have a Python 2 buildbot to test for regressions
> * For semver reasons we should drop Python 2.7 support in Sage 10, not 9.1
>
> Having said that, I'm fine with an accelerated Sage 9 -> Sage 10 schedule, 
> maybe a month or two instead of the usual 3-4. Though first we should take 
> the opportunity and see if there are any outstanding Python 3 bugs now that 
> we have more data. For example it would be nice if a build with 
> SAGE_DEBUG=yes would pass tests. There are a few more regressions, e.g. #28817

Accelerated is fine, but I should add that fully *removing* Python 2
support is not a trivial task either (it's mostly mechanical work, but
there's a LOT of it).  https://trac.sagemath.org/ticket/28000 has a
few steps towards it but is far from complete.

Fully removing Python 2-isms from the codebase is not necessarily a
prerequisite to dropping Python 2 support, but I would be hesitant to
leave a monstrous partially-hybrid codebase around for too long.

-- 
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%3DpXaDP5ByS2pAf45HgL-0gOkrTdcGFzSZsAc24rgR%3Dw%40mail.gmail.com.