On Wednesday, June 5, 2024 at 5:31:30 AM UTC-7 Oscar Benjamin wrote: My question here is: would it be problematic for Sage if SymPy were to follow SPEC 0/NEP 29 which would mean dropping support for older Python versions more quickly?
Quick answer: Probably it would not be very problematic on our side because many of other upstream packages of Sage (NumPy, SciPy, NetworkX, ...) already follow that schedule. But it could mean that we sometimes hold off on updating SymPy to the latest version for a little while, like we currently do with other packages. Example: SPEC 0/NEP 29 dropped Python 3.9 earlier this year, and NetworkX has already pushed out a version 3.3 which no longer supports Python 3.9. But that's an outlier from our perspective; the released versions of NumPy and SciPy (including the upcoming NumPy 2.0) still support Python 3.9. So without major cost to us, we are able to keep Python 3.9 a bit longer. We are about to release SymPy 1.13 which will support Python 3.8 to 3.13. Great, I hope we can still squeeze it in to our upcoming Sage 10.4 release! It has been asked on the SymPy mailing list whether SymPy could adopt SPEC 0 which is basically the same as NEP 29: https://groups.google.com/g/sympy/c/VNz2xJ1Sywo/m/0H1-KmaJAgAJ?utm_medium=email&utm_source=footer https://scientific-python.org/specs/spec-0000/ There are older discussions about this as well: https://github.com/sympy/sympy/issues/21884 This relates to previous discussions on this list about Sage following NEP 29: https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/Ap_1pHlsBQAJ?utm_medium=email&utm_source=footer https://groups.google.com/g/sage-devel/c/3Zoq0CNE1hE/m/m40v2e_cBwAJ We also have a wiki page about NEP 29 with many collected facts and discussion points: https://github.com/sagemath/sage/wiki/NEP-29:-Python-version-strategy (last edited by me in October 2023; should update for SPEC 0 etc.) Ordinarily SymPy would have dropped support for Python 3.8 by now anyway regardless of SPEC 0 or NEP 29. I can't remember where this was discussed but I think that the reason Python 3.8 is still supported is just because we thought it was needed by Sage. We dropped Python 3.8 in the Sage 10.2 cycle (August 2023). Following those specifications in coordination with other scientific Python packages would mean dropping both 3.8 and 3.9 now and then also dropping 3.10 in a few months. I don't propose to do this right now with the SymPy 1.13 release but once 1.13 is released I want to drop at least 3.8 if not also 3.9 No problem; by the time that SymPy 1.14 is ready, we'll likely have dropped 3.9. It is not particularly difficult for SymPy itself to support a wide range of Python versions Likewise for the Sage library. Personally I am in favour of SymPy coordinating with the rest of the scientific Python ecosystem by adopting SPEC 0/NEP 29 so that there is a clearly defined policy that is understood and depended on by everything downstream. Old versions of SymPy will continue to work with old versions of Python so people who like packaging old versions of everything (e.g. Linux distros) can do so. Yes, this makes sense and is, of course, very much the point of SPEC 0/NEP 29. As Sage currently is "downstream of everything" and "upstream of nothing", we have effectively been following NEP 29 + an additive constant. See https://github.com/sagemath/sage/wiki/NEP-29:-Python-version-strategy#schedule-with-comparison-to-nep-29 (I hope that this will change in the longer term with the modularization of the Sage library, but currently it is not a relevant factor.) [...Remarks on pyenv, uv, vscode, conda elided...] It is not clear to me what the benefit is of supporting old Python versions especially for Sage: building/installing Sage is a vastly bigger issue than building/installing a new Python version. One important factor regarding on our side has really been cultural rather than technical: To counter the perception that "Sage is so isolated from the rest of the world, it even brings its own Python", we have gone to great lengths to support the use of (venvs over) the system-provided Python; even though that goes counter to the common mantra among Python devs that "system Python is not for you". Because of this, the available (and default) Python versions on common distributions have been a factor in our version support strategy. -- 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/14718742-f2d6-4942-9502-049508020210n%40googlegroups.com.
