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.
