I am for adapting NEP 29 for Sage (and thus dropping Python 3.8 now). Few comments on the Summary:
2) it's very important to be in sync with various Sage's upstream parts, as much as possible. We don't want to lag behind, preventing us from being able to use latest versions. 3) Saying that Python 3.8 is still supported, by python.org, is not 100% correct. (it's supported as being on life support :-)) Python 3.8 is still getting security updates - it does not get any other bugs fixed. The only Python version getting the bugfixes is now 3.11, the older Python versions are legacy versions. See https://devguide.python.org/versions/ On Fri, May 26, 2023 at 11:12 AM Tobias Diez <tobiasdiez...@gmail.com> wrote: > > Dear Sage developers, > > the NumPy enhancement proposal 29: "Recommend Python and Numpy version > support as a community policy standard" (available at > https://numpy.org/neps/nep-0029-deprecation_policy.html) specifies when it's > okay to drop support for old Python version. > > Namely, a release should support "all minor versions of Python released 42 > months prior to the project, and at minimum the two latest minor versions. ". > In particular, this means: > - Currently, Sage should support > 3.8. > - On Apr 05, 2024 we should drop support for Python 3.9 (initially released > on Oct 05, 2020) > > Based on previous discussions on this topic > (https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/2sTiwdKPBQAJ, > https://github.com/sagemath/sage/issues/30384, > https://github.com/sagemath/sage/pull/35403), I'm calling for a vote on > adapting the Python version support of NEP 29 in Sage. Voting ends at the 7th > June, AoE. Please use this thread only for sending votes, to make it easier > to count them afterward; and use the thread > https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/2sTiwdKPBQAJ for > discussion. > > Summary of the points brought forward in the discussions linked above > 1. The current practice in Sage is to evaluate whether to increase the > minimum version of Python supported at the beginning of each release cycle. > With regard to such a practice, the NEP 29 documents remarks "As there is no > objective threshold to when the minimum version should be dropped, it is easy > for these version support discussions to devolve into bike shedding and > acrimony." Sadly, an example of this can be found in the current discussion > of dropping Python 3.8 support in https://github.com/sagemath/sage/pull/35404 > with emotions running so high that sage-abuse had to step in. Adopting a > version policy would prevent such discussions. On the other hand, by > following a given policy, we would loose some flexibility. > 2. The main idea of NEP 29 is to have a community-wide standard. It is > followed by many scientific packages such as Scipy, Matplotlib, IPython, > Jupyter, Pandas, scikit, astropy, cuda, cirq, jax, pytorch among others. The > adoption of NEP 29 will harmonize Sage's deprecation policy with these other > major libraries. > 3. The NEP 29 drop schedule is much faster than the EOL schedule of Python > itself. Python 3.8 is supported until 2024-10, but NEP 29 already drops it > 2023-04. However, adhering to the EOL schedule would prevent us to updating > these packages that follow NEP 29. > 4. The NEP 29 schedule is about one release cycle faster than the previous > drops (e.g. Python 3.7 support was dropped in Sage 9.7 while according to NEP > 29 it would have been Sage 9.6). > 5. The faster drop schedule will free developer resources (less systems to > test) and potentially increase developer productivity as it allows us to use > newer language features. > 6. The faster drop schedule might be inconvenient for users who rely on older > Python versions. To some extend this is remedied by our python install > package, and relatively straightforward upgrade paths on most system. One > should also note that users relying on other scientific python packages are > likely forced to upgrade anyway, since these other packages likely follow NEP > 29. > 7. The faster drop schedule would force users to upgrade to newer Python > versions and thereby profit from fewer bugs and security issues. It is > however questionable if Sage should play this educator role. > 8. One of the main goals of NEP 29 is to improve downstream project planning > by having a community-wide standard. This is currently not very relevant for > us as Sage is currently upstream of nothing except for some user packages. > With the modularization effort, this may change in the future. > 9. There are not many other documented policies. As said above, most > scientific python projects follow NEP 29. Most projects in web development > (e.g flask) seem to drop a version once it reaches EOL. Machine learning > projects follow a similar EOL policy (e.g. tensorflow) or roughly follow NEP > 29 (scikit-learn). Some end-user applications have even stricter version > constraints then NEP 29 (e.g. home-assistant only supports the two latest > minor releases). > > -- > 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/d321fa7e-47d0-40ed-9468-e090b11cb86fn%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/CAAWYfq0YQ63sSGA-Sw2ZNYfRTi48WXCE8BNTXB1-PUqRj1LbUQ%40mail.gmail.com.
