[sage-devel] Download-statistics of Sage related PyPI packages

[seb....@gmail.com]

I queried such data stored between January 2016 and April 2023 and put it 
into a read-only SQLite database. If you're interested, check out this DBHub 
database . 
Scroll down to read how to visualize the data.

I used a Google free trial service account 
 for 
this. I plan on extracting some more data (and then happily escaping the 
lion's den) before the July expiration. So if you are the maintainer of a 
project that is now missing, adding the *SageMath* keyword to the PyPI 
repository before July will add it. Alternatively, you can also report this 
on the discussion-chanel on DBHub.


Concerning the discussion in the NEP29 thread, I think the following query 
is interesting:

select python, sum(num_downloads) num_downloads from sage_pypi_packages 
where date > '2023-02-28' and installer in ('pip', 'Browser') and python 
NOT NULL group by python order by 2 desc

python  num_downloads
-
3.8.10  13301
3.9.5   13207
3.9.16  12371
3.8.16  11158
3.7.16  7309
3.10.10 4085
3.7.4   3847
3.7.10  3502
3.7.5   2771
3.11.2  2723
3.10.6  2082
3.10.8  2027
3.9.13  1684
3.10.11 1660
3.10.9  1495
3.8.12  1415
3.7.12  1308
3.7.15  1161
3.9.2   1123
3.9.15  1121
3.7.11  866
...

-- 
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/b11ecb46-d378-4d62-a3dd-3d3d2030c580n%40googlegroups.com.

Re: [sage-devel] Re: Can I build Sage via MacPorts under MacOS 10.9?

[Louis Deaett]

Aha – thank you!  I will start playing with this...

– Louis


On Monday, May 22, 2023 at 12:17:56 PM UTC-4 Dima Pasechnik wrote:

> On Mon, May 22, 2023 at 4:53 PM Dima Pasechnik  wrote:
> >
> > On Mon, May 22, 2023 at 3:09 AM Louis Deaett  
> wrote:
> > >
> > > Many thanks for the word of encouragement, and also for pointing me to 
> that ticket. I was not even familiar with tox, to be honest, so I read up 
> on its intended purpose.
> > >
> > > I can see that the source for Sage 9.7 that I have here has a tox.ini 
> file, but inside there is no reference to MacPorts. Is that because the 
> MacPorts environments alluded to in the thread (the one you linked) haven't 
> been merged into the release branch of Sage?
> > >
> > > After further digging, I did notice this branch:
> > >
> > > 
> https://github.com/sagemath/sagetrac-mirror/tree/u/mkoeppe/tox_ini__add_macports_environment
> > >
> > > It looks like it hasn't seen any commits in almost a year. But is that 
> still my best starting point? Shall I pick up and work with this, or has 
> this effort been abandoned?
> >
> > indeed, no work had been done since.
> > A good starting point would be to take it rebased over the latest 
> develop, here:
> > 
> https://github.com/dimpase/sage/pull/new/u/mkoeppe/tox_ini__add_macports_environment
>
> Oops, I meant to post this: https://github.com/sagemath/sage/pull/35667
> (same branch, as a PR)
> >
> > HTH
> > Dima
> >
> >
> > >
> > > Many thanks again!
> > >
> > > – Louis
> > >
> > >
> > > On Friday, May 5, 2023 at 2:42:19 PM UTC-4 John H Palmieri wrote:
> > >>
> > >> In principle this should work. See 
> https://github.com/sagemath/sage/issues/31505 for some relevant 
> information. Others might have direct experience with it.
> > >>
> > >> On Friday, May 5, 2023 at 11:24:07 AM UTC-7 Louis Deaett wrote:
> > >>>
> > >>> I'm interested in Sage development (and contributing some 
> enhancements) and so I'd like to be able to build the current release (and 
> ultimately the development branch) from source.
> > >>>
> > >>> I am running macOS 10.9 (Mavericks) because that is what I prefer, 
> and because some of my hardware tops out at that version. Anyway, I've had 
> decent success getting open-source software up and running under MacPorts, 
> which has good support for 10.9 (and even earlier).
> > >>>
> > >>> So I've been working on building Sage from source using MacPorts. 
> Compilation seems to go smoothly with MacPorts LLVM tools, but I've run 
> into some snags whereby the build for some SPKGs seems to get gummed up 
> when it can't locate some of the libraries or headers provided by MacPorts. 
> By its nature, this hasn't felt like an insurmountable problem.
> > >>>
> > >>> Still, while I can keep hacking away at this, I figured I should 
> ask: Is there any fundamental reason why what I'm trying to do should be 
> impossible?
> > >>>
> > >>> If there are major barriers in my path with this that I'm just not 
> encountering yet or just haven't realized, then it would (of course) help 
> me out to know.
> > >>>
> > >>> For what it's worth, if building under MacPorts is theoretically 
> possible but would require some additional effort on the Sage side, then 
> that's something I'd be willing to contribute to, if anything comes out of 
> my own efforts.
> > >>>
> > >>> Thanks in advance for any advice!
> > >>>
> > >>> -- Louis
> > >
> > > --
> > > 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+...@googlegroups.com.
> > > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/5a8f7076-fcb4-462d-8c48-a7b1c7fea26dn%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/5fddf3e4-2de2-4634-a48c-b91eff3c660an%40googlegroups.com.

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[Michael Orlitzky]

On Fri, 2023-05-26 at 18:15 +0100, Oscar Benjamin wrote:
> 
> What is wrong with Sage just saying that an older version of an
> operating system only works with an older version of Sage?

Matthias alluded to this when he mentioned that we only have one
release branch of sage. Our version numbers are not really meaningful,
and bug fixes and features are released simultaneously. So the only way
to get fixes for critical bugs is to upgrade, but the upgrades come
with new features, and those new features can have new requirements.

That said, I still share your sentiment when there is a good reason (a
term best left undefined) to break compatibility.

-- 
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/5128635b3e20e95ac427986ac656db8789b62e80.camel%40orlitzky.com.

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[Matthias Koeppe]

On Friday, May 26, 2023 at 9:19:52 AM UTC-7 Dima Pasechnik wrote:

On Fri, May 26, 2023 at 5:01 PM Matthias Koeppe 
 wrote: 
> > d) In contrast, our uses of NumPy/SciPy in the Sage library are very 
basic 
> > and dating back by about a decade; 
> No, not true. E.g. 
> schemes/riemann_surfaces/riemann_surface.py is neither "basic" nor 
> dating back that much - it's also under relatively active development, 
see its header: 
> - Alexandre Zotine, Nils Bruin (2017-06-10) [...]  (2022-09-07): 
Abel-Jacobi map 
> It's using Voronoi diagrams from scipy. 
> 
> Well, scipy.spatial.Voronoi was added in SciPy 0.12.0 (
https://docs.scipy.org/doc/scipy/reference/generated/scipy.spatial.Voronoi.html),
 
released pretty much exactly a decade ago -- 
https://pypi.org/project/scipy/#history 

1) You wrote: "OUR USES of NumPy/SciPy are ... dating back by about a 
decade". 
2) I replied that it's not true, Voronoi's USE in Sage in much more recent. 
3) You are now trying to invalidate what I wrote by telling us about 
the history of Voronoi in SciPy. How is it relevant to 1) and 2) ? 
See, what you wrote is FACTUALLY INCORRECT. Please admit it


Yes, I confess that "dating back" was not worded clearly enough. I'm sorry 
that I offended you with that.

I should have said "our uses of NumPy/SciPy are of NumPy/SciPy features 
that date back by about a decade".

Which is exactly the point I was making: When we update NumPy/SciPy, it is 
typically NOT because of the needs of the Sage library for new features but 
because we want to stay on supported versions, for picking up portability 
fixes, etc., and for the convenience of the maintainers of downstream 
packaging of Sage in Linux distributions.

The only exception that I'm aware of being the high-performance 
optimization solver HiGHS, see 
https://github.com/sagemath/sage/wiki/Sage-10.0-Release-Tour#linear-programming-and-extensions
). 
Do you know others?

-- 
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/d192e862-250c-45cd-8a27-2a9d113f41ebn%40googlegroups.com.

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[Oscar Benjamin]

On Fri, 26 May 2023 at 16:19, William Stein  wrote:
>
> On Fri, May 26, 2023 at 7:57 AM  wrote:
> > > a) Sage has a dual role as a library ("project") and as a distribution. 
> > > NEP
> > > 29 was designed for projects, and not for software distributions.
> >
> > No, Sage is just a project, with lots of dependencies (way too many).
> > It's not a software distribution in any way, it does not include
> > essential tools to build it (e.g. no C/C++ compiler on macos).
...
>
> In the nearly two decades since starting Sage,  software distribution
> and the Python
> ecosystem have improved enough that there is hope that Sage could
> transition to just
> being a bunch of libraries, and all the distribution gets handled by some
> third party distribution such as conda (etc.).   That's been discussed
> with great optimism
> recently on this list.
>
> I hope soon Sage isn't a distribution, but right now it still is.

Usually a distribution tries to include everything so that it can
constrain the versions. That would imply that if Sage is a
distribution then it should also distribute its own Python or the Sage
versions should be constrained by the Python versions. Then it would
not be necessary for any single version of Sage to have compatibility
with multiple versions of Python. A Linux distro does not try to
support many different Python versions using the same versions of
Python packages. Each version of the distro will update the Python
version and also the version of NumPy, SymPy etc simultaneously.

The intention of NEP 29 is for various libraries such as NumPy to
coordinate on ensuring that there exists some mutually consistent set
of versions that can be used together either right now or some time in
the future. It isn't necessary for newer NumPy versions to support
significantly older Python versions because if you want to use an
older version of Python then you can just use an older version of
NumPy (which is precisely what a distro would do in any case). There
are then two ways that those consistent versions get used:

- Some people will use Python packaging tools to install the latest
versions of things from PyPI and the most recent versions of packages
are designed to be consistent with the most recent versions of Python.
- Distributions like conda or Linux distros will use some consistent
set of older versions i.e. an older version of Python *and* older
versions of the packages.

It sounds to me like Sage is trying to live in between these two
things and potentially ends up trying to mix older and newer versions
together which will always be painful because no one else is trying to
make that work.

What is wrong with Sage just saying that an older version of an
operating system only works with an older version of Sage?

Maybe if you want to use the latest version of Sage on some old
version of Debian then you should just install a newer version of
Python first?

Sage 10 might be better than Sage 9 but Sage 9 was still good before
Sage 10 came along. Is it so bad that someone might need to wait until
they are ready to upgrade other things before getting the latest
version of Sage?

There are many different levels at which you can ask these questions
about exactly which new things should be compatible with which older
things. The purpose of NEP 29 is that there should exist some rolling
set of consistent package versions that aligns with the releases of
Python itself. It is then up to downstream to decide whether they want
the latest stuff fresh off the press today or if they would rather
wait and use 5 years old versions of things.

> There are follow up discussions, just like this one, by other projects, e.g., 
> for sympy here:
> https://github.com/sympy/sympy/issues/21884,

The situation for SymPy is very different from NumPy because it is
really not a big burden for SymPy to support Python 3.8 being only
pure Python. SymPy's release is just a single wheel that works on any
OS, all versions of Python, both CPython and PyPy etc. NumPy has to
provide and test many more binaries and also uses CPython's C API
which has bigger cost in compatibility problems across Python
versions.

That being said the cost to SymPy is not zero and in some ways
discussions like this about which version to support can just be time
wasted that could be spent on better things. In the SymPy issue
Matthias suggested that it is useful for Sage if SymPy continues to
have wider version support. Since it is not a big cost it is fine for
SymPy to do that. Otherwise though I would probably push for SymPy
adopting NEP 29 just because it is a documented policy and it is good
if everyone both in the project and downstream can see a clear policy
and knows what to expect.

--
Oscar

-- 
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 v

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[Tobias Diez]

> I have the impression that NEP 29 tried to very 
rigidly define end of life by a specific timeline with no flexibility 
for the potential that the official Python release timelines are not 
rigid and fixed in stone forever 

The PR linked above mentions quite often that they do take 
variations/changes of the Python release schedule into account. For 
example, NEP 29 writes " support at least all minor versions of Python 
introduced and released in the prior 42 months *from the anticipated 
release date* with a minimum of 2 minor versions of Python". With a rigid 
schedule, this is a unnecessary duplication - but the "at least two minor 
versions" is there to prevent the worst case scenario where python releases 
are delayed by a few years and no python version would be supported 
otherwise. But yes, naturally there are some included expectations about 
the Python release schedule included in NEP 29 and it would probably be 
revised if Python changes its schedule. Conversely, NEP 29 is adapted by so 
many libraries that Python itself includes it in discussions about its 
release schedule (e.g. 
https://peps.python.org/pep-0605/#implications-for-the-proposed-scientific-python-ecosystem-support-period)

On Saturday, 27 May 2023 at 00:56:12 UTC+8 Tobias Diez wrote:

> Here is the PR that introduced NEP 29: 
> https://github.com/numpy/numpy/pull/14086. The main discussion happened 
> in person at scipy 2019 and in webcalls. But a lot of the points raised 
> here are answered in this PR.
>
> For example, the point about Linux LTS / Python EOL is addressed by one of 
> the writers of NEP 29 as follows (
> https://github.com/numpy/numpy/pull/14086#issuecomment-516661140)
> " 
>
> Conversely, I am not sure of a real world example where a user must have:
>
>- 4 year old version of Python
>- just-released version of numpy / Matplotilb / scikit-learn [add sage 
>here]
>
> If you are making the choice to stay on an old version of Python (which 
> there are good reasons to do!) then why would you not *also* make the 
> conservative choice to stay on the contemporaneous version of the scipy 
> stack?
> "
>
> The point that "NEP is about libraries and not downstream applications" is 
> also not valid since this clearly was part of the discussion back then. For 
> example, one of the core maintainers of jupyter and ipython writes 
> https://github.com/numpy/numpy/pull/14086#issuecomment-516904953
> " There is also the same catch 22 than dropping python 2; downstream was 
> not dropping because upstream was still supporting Python 2, and upstream 
> was still supporting Python 2 because downstream was relying on it."
> In other words, if all downstream applications would have a more 
> conservative policy, then naturally also numpy etc would need to adapt. NEP 
> 29 is about homogenizing the supported Python version in the scientific 
> python community. This is also very clearly written in the first line of 
> the NEP: "recommends that *all projects *across the Scientific Python 
> ecosystem adopt a common “time window-based” policy for support of Python 
> and NumPy versions" (emphasize mine). Its "all projects", not "all upstream 
> libraries". So unless someone wants to argue that sage is not part of the 
> scientific python ecosystem, we are directly addressed.
>
> By the way, what happened to the "please let the discussion go somewhere 
> else"? Should I restart the voting in a new thread?
> On Friday, 26 May 2023 at 23:10:52 UTC+8 William Stein wrote:
>
>> Hi, 
>>
>> To help with people who want to make an informed decision, is there 
>> any public discussion of the original NEP 29 proposal? 
>>
>> The only thing I could find was this post from Sebastian Berg, where he 
>> says at 
>>
>>
>> https://mail.python.org/pipermail/numpy-discussion/2019-October/080128.html 
>>
>> "We propose formally accepting the NumPy enhancement proposal 29... If 
>> there are no objections within a week it may be accepted.". 
>> There's no public voting or anything, and there's exactly one quick 
>> random response of "yes" in the thread. 
>>
>> In the actual NEP 29 proposal 
>> https://numpy.org/neps/nep-0029-deprecation_policy.html there is a 
>> section labeled "Discussion" and it is empty. 
>> I would love to read about the discussions for/against NEP 29 from 
>> when they decided on it in the first place! 
>>
>> There are follow up discussions, just like this one, by other 
>> projects, e.g., for sympy here: 
>> https://github.com/sympy/sympy/issues/21884, which 
>> is still not decided, and has been under regular discussion for nearly 
>> 2 years. There are many other similar conversations. But they are 
>> all about whether to align with numpy or not, and the core question of 
>> why it is best to ignore what the official upstream python supports 
>> isn't as relevant. 
>>
>> The original NEP 29 says "The Python release cadence increased in PEP 
>> 0602, [...] Thus, we do not expect our users to upgrade Python f

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[Tobias Diez]

Here is the PR that introduced NEP 29: 
https://github.com/numpy/numpy/pull/14086. The main discussion happened in 
person at scipy 2019 and in webcalls. But a lot of the points raised here 
are answered in this PR.

For example, the point about Linux LTS / Python EOL is addressed by one of 
the writers of NEP 29 as follows 
(https://github.com/numpy/numpy/pull/14086#issuecomment-516661140)
" 

Conversely, I am not sure of a real world example where a user must have:

   - 4 year old version of Python
   - just-released version of numpy / Matplotilb / scikit-learn [add sage 
   here]
   
If you are making the choice to stay on an old version of Python (which 
there are good reasons to do!) then why would you not *also* make the 
conservative choice to stay on the contemporaneous version of the scipy 
stack?
"

The point that "NEP is about libraries and not downstream applications" is 
also not valid since this clearly was part of the discussion back then. For 
example, one of the core maintainers of jupyter and ipython writes 
https://github.com/numpy/numpy/pull/14086#issuecomment-516904953
" There is also the same catch 22 than dropping python 2; downstream was 
not dropping because upstream was still supporting Python 2, and upstream 
was still supporting Python 2 because downstream was relying on it."
In other words, if all downstream applications would have a more 
conservative policy, then naturally also numpy etc would need to adapt. NEP 
29 is about homogenizing the supported Python version in the scientific 
python community. This is also very clearly written in the first line of 
the NEP: "recommends that *all projects *across the Scientific Python 
ecosystem adopt a common “time window-based” policy for support of Python 
and NumPy versions" (emphasize mine). Its "all projects", not "all upstream 
libraries". So unless someone wants to argue that sage is not part of the 
scientific python ecosystem, we are directly addressed.

By the way, what happened to the "please let the discussion go somewhere 
else"? Should I restart the voting in a new thread?
On Friday, 26 May 2023 at 23:10:52 UTC+8 William Stein wrote:

> Hi,
>
> To help with people who want to make an informed decision, is there
> any public discussion of the original NEP 29 proposal?
>
> The only thing I could find was this post from Sebastian Berg, where he 
> says at
>
> https://mail.python.org/pipermail/numpy-discussion/2019-October/080128.html
>
> "We propose formally accepting the NumPy enhancement proposal 29... If
> there are no objections within a week it may be accepted.".
> There's no public voting or anything, and there's exactly one quick
> random response of "yes" in the thread.
>
> In the actual NEP 29 proposal
> https://numpy.org/neps/nep-0029-deprecation_policy.html there is a
> section labeled "Discussion" and it is empty.
> I would love to read about the discussions for/against NEP 29 from
> when they decided on it in the first place!
>
> There are follow up discussions, just like this one, by other
> projects, e.g., for sympy here:
> https://github.com/sympy/sympy/issues/21884, which
> is still not decided, and has been under regular discussion for nearly
> 2 years. There are many other similar conversations. But they are
> all about whether to align with numpy or not, and the core question of
> why it is best to ignore what the official upstream python supports
> isn't as relevant.
>
> The original NEP 29 says "The Python release cadence increased in PEP
> 0602, [...] Thus, we do not expect our users to upgrade Python faster,
> and our 42 month support window will cover the same portion of the
> upstream support of any given Python release." I don't really know
> what that means, but I have the impression that NEP 29 tried to very
> rigidly define end of life by a specific timeline with no flexibility
> for the potential that the official Python release timelines are not
> rigid and fixed in stone forever, while simultaneously acknowledging
> this conflict. I would love to see the arguments for doing that,
> which could be compelling. I fully realize that this is something
> that came from maintainers of open source software, and they were
> probably feeling annoyed and burned out, and this NEP 29 may have
> helped them keep their sanity. But if that's the case, it's decided
> in secret as far as I can tell.
>
> -- William
>
> On Fri, May 26, 2023 at 6:34 AM Matthias Koeppe
>  wrote:
> >
> > Thanks, Tobias, for opening this vote thread. Here on sage-devel, this 
> is a much better setting than what you attempted in 
> https://github.com/sagemath/sage/pull/35404#issuecomment-1504474945
> >
> > I am voting NO.
> >
> > There's a simple rationale:
> >
> > I. This proposed policy change does not solve any problem. There are no 
> problems whatsoever with how we have managed the support of Python versions 
> since 2020 (when it became possible to use system Python instead of only 
> the Python from our SPKG.)
> >
> > II. 

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[William Stein]

On Fri, May 26, 2023 at 9:19 AM Dima Pasechnik  wrote:
> Please admit it, otherwise.  I don't see a way to continue a discussion with 
> you.

Can you please continue to engage, but view this as a public debate
for the benefit of all sage developers, rather than a discussion with
Matthias?  It's a debate.  It's the sort of heated discussion about
NEP 29 that I wish I could read, but (maybe) I can't because some
"powers that be" just decided on NEP 29 in private (which is their
right of course as volunteers and open source maintainers).


 -- William

--
William (http://wstein.org)

-- 
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/CACLE5GCKLVTNpmCnY5jYpbKnse0K71%2BMZsU%2BY4PxWJW-cG0FaA%40mail.gmail.com.

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[Dima Pasechnik]

On Fri, May 26, 2023 at 5:01 PM Matthias Koeppe
 wrote:
>
> On Friday, May 26, 2023 at 7:57:53 AM UTC-7 dim...@gmail.com wrote:
>
> On Fri, May 26, 2023 at 06:34:25AM -0700, Matthias Koeppe wrote:
> > I am voting NO.
> >
> > I. This proposed policy change does not solve any problem. There are no
> > problems whatsoever with how we have managed the support of Python versions
> > since 2020 (when it became possible to use system Python instead of only
> > the Python from our SPKG.)
> this is not true. It solves a range of problems, e.g., in no particular
> order:
>
>
> I'll be replying to one these at a time...
>
> > d) In contrast, our uses of NumPy/SciPy in the Sage library are very basic
>
> > and dating back by about a decade;
> No, not true. E.g.
>
> schemes/riemann_surfaces/riemann_surface.py is neither "basic" nor
> dating back that much - it's also under relatively active development, see 
> its header:
>
> - Alexandre Zotine, Nils Bruin (2017-06-10): initial version
> - Nils Bruin, Jeroen Sijsling (2018-01-05): algebraization, isomorphisms
> - Linden Disney-Hogg, Nils Bruin (2021-06-23): efficient integration
> - Linden Disney-Hogg, Nils Bruin (2022-09-07): Abel-Jacobi map
>
> It's using Voronoi diagrams from scipy.
>
>
> Well, scipy.spatial.Voronoi was added in SciPy 0.12.0 
> (https://docs.scipy.org/doc/scipy/reference/generated/scipy.spatial.Voronoi.html),
>  released pretty much exactly a decade ago -- 
> https://pypi.org/project/scipy/#history

1) You wrote: "OUR USES of NumPy/SciPy are ... dating back by about a decade".
2) I replied that it's not true, Voronoi's USE in Sage in much more recent.
3) You are now trying to invalidate what I wrote by telling us about
the history of Voronoi in SciPy. How is it relevant to 1) and 2) ?
See, what you wrote is FACTUALLY INCORRECT. Please admit it, otherwise
I don't see a way to continue a discussion with you.



>
> Next?
>
>
>
> --
> 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/baead8c6-65d2-4799-92c9-3e6c14ad5a62n%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/CAAWYfq3S_2iZuYYdv%2B067ZWeckeBucCB9qBfRwgdRi_DV-VedA%40mail.gmail.com.

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[Matthias Koeppe]

On Friday, May 26, 2023 at 7:57:53 AM UTC-7 dim...@gmail.com wrote:

On Fri, May 26, 2023 at 06:34:25AM -0700, Matthias Koeppe wrote: 
> I am voting NO. 
> 
> I. This proposed policy change does not solve any problem. There are no 
> problems whatsoever with how we have managed the support of Python 
versions 
> since 2020 (when it became possible to use system Python instead of only 
> the Python from our SPKG.) 
this is not true. It solves a range of problems, e.g., in no particular 
order:


I'll be replying to one these at a time...

> d) In contrast, our uses of NumPy/SciPy in the Sage library are very basic

> and dating back by about a decade; 
No, not true. E.g. 

schemes/riemann_surfaces/riemann_surface.py is neither "basic" nor 
dating back that much - it's also under relatively active development, see 
its header: 

- Alexandre Zotine, Nils Bruin (2017-06-10): initial version 
- Nils Bruin, Jeroen Sijsling (2018-01-05): algebraization, isomorphisms 
- Linden Disney-Hogg, Nils Bruin (2021-06-23): efficient integration 
- Linden Disney-Hogg, Nils Bruin (2022-09-07): Abel-Jacobi map 

It's using Voronoi diagrams from scipy.


Well, scipy.spatial.Voronoi was added in SciPy 0.12.0 
(https://docs.scipy.org/doc/scipy/reference/generated/scipy.spatial.Voronoi.html),
 
released pretty much exactly a decade ago -- 
https://pypi.org/project/scipy/#history

Next?



-- 
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/baead8c6-65d2-4799-92c9-3e6c14ad5a62n%40googlegroups.com.

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[William Stein]

On Fri, May 26, 2023 at 7:57 AM  wrote:
> > a) Sage has a dual role as a library ("project") and as a distribution. NEP
> > 29 was designed for projects, and not for software distributions.
>
> No, Sage is just a project, with lots of dependencies (way too many).
> It's not a software distribution in any way, it does not include
> essential tools to build it (e.g. no C/C++ compiler on macos).

Since I started the project in 2005 and until now Sage is definitely
both a big python library *and* a distribution.
I've given a million talks with a slide about how Sage is both a new
library of code and a distribution.   Being a
distribution was the whole reason people would consider using open
source software for math, instead of
sticking with Maple or Magma -- at least it was possible that they
could get it running on their computers.  Also,
it helped to make other open source math software beyond just sage
more accessible.

In the nearly two decades since starting Sage,  software distribution
and the Python
ecosystem have improved enough that there is hope that Sage could
transition to just
being a bunch of libraries, and all the distribution gets handled by some
third party distribution such as conda (etc.).   That's been discussed
with great optimism
recently on this list.

I hope soon Sage isn't a distribution, but right now it still is.

-- 
William (http://wstein.org)

-- 
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/CACLE5GDOqESkf6MGOm0RPNLp0_UR50sk18PVD%3DZp-Du8RARS%2BA%40mail.gmail.com.

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[William Stein]

Hi,

To help with people who want to make an informed decision, is there
any public discussion of the original NEP 29 proposal?

The only thing I could find was this post from Sebastian Berg, where he says at

https://mail.python.org/pipermail/numpy-discussion/2019-October/080128.html

"We propose formally accepting the NumPy enhancement proposal 29... If
there are no objections within a week it may be accepted.".
There's no public voting or anything, and there's exactly one quick
random response of "yes" in the thread.

In the actual NEP 29 proposal
https://numpy.org/neps/nep-0029-deprecation_policy.html there is a
section labeled "Discussion" and it is empty.
I would love to read about the discussions for/against NEP 29 from
when they decided on it in the first place!

There are follow up discussions, just like this one, by other
projects, e.g., for sympy here:
https://github.com/sympy/sympy/issues/21884, which
is still not decided, and has been under regular discussion for nearly
2 years.  There are many other similar conversations.  But they are
all about whether to align with numpy or not, and the core question of
why it is best to ignore what the official upstream python supports
isn't as relevant.

The original NEP 29 says "The Python release cadence increased in PEP
0602, [...] Thus, we do not expect our users to upgrade Python faster,
and our 42 month support window will cover the same portion of the
upstream support of any given Python release."I don't really know
what that means, but I have the impression that NEP 29 tried to very
rigidly define end of life by a specific timeline with no flexibility
for the potential that the official Python release timelines are not
rigid and fixed in stone forever, while simultaneously acknowledging
this conflict.  I would love to see the arguments for doing that,
which could be compelling.   I fully realize that this is something
that came from maintainers of open source software, and they were
probably feeling annoyed and burned out, and this NEP 29 may have
helped them keep their sanity.  But if that's the case, it's decided
in secret as far as I can tell.

 -- William

On Fri, May 26, 2023 at 6:34 AM Matthias Koeppe
 wrote:
>
> Thanks, Tobias, for opening this vote thread. Here on sage-devel, this is a 
> much better setting than what you attempted in 
> https://github.com/sagemath/sage/pull/35404#issuecomment-1504474945
>
> I am voting NO.
>
> There's a simple rationale:
>
> I. This proposed policy change does not solve any problem. There are no 
> problems whatsoever with how we have managed the support of Python versions 
> since 2020 (when it became possible to use system Python instead of only the 
> Python from our SPKG.)
>
> II. The proposed policy change creates new problems. Following this policy 
> would force us to drop support for a particular Python version at times when 
> it would be harmful for our project. Specifically, right now it would *force* 
> us to drop support for Python 3.8 and hence for using the default Python on 
> Ubuntu Linux 20.04 (an LTS release, with "End of Standard Support" April 2025 
> and "End Of Life" April 2030. It is the very point of LTS releases to provide 
> a stable software environment; so, yes, Python 3.8 is fully supported, and if 
> Python 3.8.x had bugs relevant for Sage, we would know about it because we 
> are testing.
>
> III. Our existing practice is to carefully consider and weigh various factors 
> that are relevant for the Sage project, rather than following a fixed 
> schedule that is set by an external, largely separate community. I briefly 
> explained what we do in 
> https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/x3qOdPB5BQAJ; but I'll 
> expand here on some important factors:
>
> a) Sage has a dual role as a library ("project") and as a distribution. NEP 
> 29 was designed for projects, and not for software distributions.
>
> b) In Sage, we only have one line of releases. Hence users who want any bug 
> fixes need to use our latest version. In contrast, just like Python itself, 
> many other projects have at least two separate branches: A branch on which 
> the cutting edge development takes place (new features etc.), and a branch 
> from which maintenance updates are made. For example, NumPy removed support 
> of Python 3.8 in their development branch earlier this year; but this in 
> preparation for the 1.25 release expected this summer. NumPy continued to 
> make maintenance releases on the 1.24 branch 
> (https://github.com/numpy/numpy/releases), and by policy, these maintenance 
> upgrades never drop the support of a previously supported version.
>
> c) NEP29 was designed for and is in use by a part of the scientific Python 
> community, to address the need to be able to use features of new Python 
> versions and features of NumPy/SciPy faster. This is important for many 
> projects that have NumPy/SciPy as their dependencies.
>
> d) In contrast, our uses of NumPy/SciPy in the

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[dimpase]

On Fri, May 26, 2023 at 06:34:25AM -0700, Matthias Koeppe wrote:
> Thanks, Tobias, for opening this vote thread. Here on sage-devel, this is a 
> much better setting than what you attempted 
> in https://github.com/sagemath/sage/pull/35404#issuecomment-1504474945
> 
> I am voting NO.
> 
> There's a simple rationale: 
> 
> I. This proposed policy change does not solve any problem. There are no 
> problems whatsoever with how we have managed the support of Python versions 
> since 2020 (when it became possible to use system Python instead of only 
> the Python from our SPKG.) 
this is not true. It solves a range of problems, e.g., in no particular
order:
1) lack of hands to support all that obsolete versions, 
2) blocking new Python features in 3.9 from being used in Sage
3) falling behind w.r.t. versions of various Python packages used in Sage,
packages which are already merging 3.8-incompatible code, e.g. networkx,
scipy, etc.
4) keeping special backported to Python 3.8 packages (at least one such
package exists) 
> 
> II. The proposed policy change creates new problems. Following this policy 
> would force us to drop support for a particular Python version at times 
> when it would be harmful for our project. Specifically, right now it would 
> *force* us to drop support for Python 3.8 and hence for using the default 
> Python on Ubuntu Linux 20.04 (an LTS release, with "End of Standard 
> Support" April 2025 and "End Of Life" April 2030. It is the very point of 
> LTS releases to provide a stable software environment;


No, this is not a problem, as Ubuntu Linux 20.04 provides a Python 3.9
system package, which can be installed and used if desired.
(And there are other options, e.g. pyenv, conda, etc)
And we have a long story of supporting Linux distros with system Python
being much older than the one needed by Sage.
It's also not clear what you propose in this respect - support Python
3.8 until Ubuntu 20.04 reaches EOL (which is much longer than Python's
3.8. EOL).

> so, yes, Python 3.8 
> is fully supported, and if Python 3.8.x had bugs relevant for Sage, we 
> would know about it because we are testing. 

Python 3.8 is not "fully supported". It's on life support, only
receiving security-related fixes, but no other fixes.
The only fully supported Python is 3.11, which does get bug fixes
for all the bugs found.

> 
> III. Our existing practice is to carefully consider and weigh various 
> factors that are relevant for the Sage project, rather than following a 
> fixed schedule that is set by an external, largely separate community. I 
> briefly explained what we do in 
> https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/x3qOdPB5BQAJ; but 
> I'll expand here on some important factors:
> 
> a) Sage has a dual role as a library ("project") and as a distribution. NEP 
> 29 was designed for projects, and not for software distributions.

No, Sage is just a project, with lots of dependencies (way too many).
It's not a software distribution in any way, it does not include
essential tools to build it (e.g. no C/C++ compiler on macos).

> 
> b) In Sage, we only have one line of releases. Hence users who want any bug 
> fixes need to use our latest version. In contrast, just like Python itself, 
no, Sage is more like Python - you don't get the bug fixed in Python 3.10 or
older!

> many other projects have at least two separate branches: A branch on which 
> the cutting edge development takes place (new features etc.), and a branch 
> from which maintenance updates are made. For example, NumPy removed support 
> of Python 3.8 in their development branch earlier this year; but this in 
> preparation for the 1.25 release expected this summer.
Do you propose to fall behind Numpy?
Dropping Python 3.8 now will let us to be ready to upgrade our Numpy.

> NumPy continued to 
> make maintenance releases on the 1.24 branch 
> (https://github.com/numpy/numpy/releases), and by policy, these maintenance 
> upgrades never drop the support of a previously supported version.
> 
> c) NEP29 was designed for and is in use by a part of the scientific Python 
> community, to address the need to be able to use features of new Python 
> versions and features of NumPy/SciPy faster. This is important for many 
> projects that have NumPy/SciPy as their dependencies. 
> 
> d) In contrast, our uses of NumPy/SciPy in the Sage library are very basic 
> and dating back by about a decade;
No, not true. E.g.

schemes/riemann_surfaces/riemann_surface.py is neither "basic" nor
dating back that much - it's also  under relatively active development, see its 
header:

- Alexandre Zotine, Nils Bruin (2017-06-10): initial version
- Nils Bruin, Jeroen Sijsling (2018-01-05): algebraization, isomorphisms
- Linden Disney-Hogg, Nils Bruin (2021-06-23): efficient integration
- Linden Disney-Hogg, Nils Bruin (2022-09-07): Abel-Jacobi map

It's using Voronoi diagrams from scipy.


> with the exception of the optional use 
> of a recent SciPy feature (the 

[sage-devel] Re: Follow NEP 29: Recommended Python version

[Matthias Koeppe]

For easy reference: Tobias has proposed a vote on this question in the 
sage-devel thread https://groups.google.com/g/sage-devel/c/3Zoq0CNE1hE



On Friday, February 24, 2023 at 7:10:07 PM UTC-8 Tobias Diez wrote:

> Hi all, 
>
> I propose to follow 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
>
> In essence it 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:
> - On Apr 14, 2023 drop support for Python 3.8 (initially released on Oct 
> 14, 2019) 
> - On Apr 05, 2024 drop support for Python 3.9 (initially released on Oct 
> 05, 2020)
>
> The main idea of NEP 29 is to have a community-wide standard to prevent 
> issues with e.g. dependencies dropping support for older Python versions to 
> early. It is followed by many scientific packages such as Scipy, 
> Matplotlib, and IPython, among others. Sage itself is also roughly 
> following it (based on the past drops, e.g. Python 3.7 support was dropped 
> 9 months ago and NEP recommends Dec 26, 2021). But as far as I'm aware 
> there is not yet a clear policy for when to drop support for older versions.
>
> Of course, the dates in the NEP 29 are only a guideline and not set in 
> stone, e.g. you don't want to drop support at the end of the release cycle 
> just because the NEP says so. But for example, Sage 10 will be most likely 
> released after Apr 14 2023, so we can now already drop support for Python 
> 3.8.
>
> Relevant issue: https://github.com/sagemath/sage/issues/30384
>
>

-- 
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/924dbcb4-1695-4688-b732-5258e8e9b61cn%40googlegroups.com.

[sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[Matthias Koeppe]

Thanks, Tobias, for opening this vote thread. Here on sage-devel, this is a 
much better setting than what you attempted 
in https://github.com/sagemath/sage/pull/35404#issuecomment-1504474945

I am voting NO.

There's a simple rationale: 

I. This proposed policy change does not solve any problem. There are no 
problems whatsoever with how we have managed the support of Python versions 
since 2020 (when it became possible to use system Python instead of only 
the Python from our SPKG.) 

II. The proposed policy change creates new problems. Following this policy 
would force us to drop support for a particular Python version at times 
when it would be harmful for our project. Specifically, right now it would 
*force* us to drop support for Python 3.8 and hence for using the default 
Python on Ubuntu Linux 20.04 (an LTS release, with "End of Standard 
Support" April 2025 and "End Of Life" April 2030. It is the very point of 
LTS releases to provide a stable software environment; so, yes, Python 3.8 
is fully supported, and if Python 3.8.x had bugs relevant for Sage, we 
would know about it because we are testing. 

III. Our existing practice is to carefully consider and weigh various 
factors that are relevant for the Sage project, rather than following a 
fixed schedule that is set by an external, largely separate community. I 
briefly explained what we do in 
https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/x3qOdPB5BQAJ; but 
I'll expand here on some important factors:

a) Sage has a dual role as a library ("project") and as a distribution. NEP 
29 was designed for projects, and not for software distributions.

b) In Sage, we only have one line of releases. Hence users who want any bug 
fixes need to use our latest version. In contrast, just like Python itself, 
many other projects have at least two separate branches: A branch on which 
the cutting edge development takes place (new features etc.), and a branch 
from which maintenance updates are made. For example, NumPy removed support 
of Python 3.8 in their development branch earlier this year; but this in 
preparation for the 1.25 release expected this summer. NumPy continued to 
make maintenance releases on the 1.24 branch 
(https://github.com/numpy/numpy/releases), and by policy, these maintenance 
upgrades never drop the support of a previously supported version.

c) NEP29 was designed for and is in use by a part of the scientific Python 
community, to address the need to be able to use features of new Python 
versions and features of NumPy/SciPy faster. This is important for many 
projects that have NumPy/SciPy as their dependencies. 

d) In contrast, our uses of NumPy/SciPy in the Sage library are very basic 
and dating back by about a decade; with the exception of the optional use 
of a recent SciPy feature (the high-performance optimization solver HiGHS, 
see 
https://github.com/sagemath/sage/wiki/Sage-10.0-Release-Tour#linear-programming-and-extensions),
 
which motivated our quick upgrade to the current SciPy version in Sage. And 
as another example, also our use of matplotlib in the library dates back by 
a decade or more; we regularly have to update when new matplotlib versions 
come out that make API changes, but we haven't picked up any new features 
in a very long time.

e) Yes, synchronization between projects matters for maintainability. But 
Sage is downstream of lots of Python packages; before we can offer support 
for a new version of Python, we often have to wait until all or most of our 
dependencies provide support for that new version. For example, some 
projects are actively working on support for the Python 3.12 release 
expected this early Fall; but for us, this is not actionable because we 
have to wait for critical dependencies; 
see https://github.com/sagemath/sage/issues/34788 . Likewise, it is not 
useful for us to drop support for an old version before there is a clear 
benefit for us, brought for example by important upgrades that have dropped 
support already.


(As suggested by Tobias, any discussion of my explanations above is best 
sent to 
the https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/2sTiwdKPBQAJ 
thread.)


On Friday, May 26, 2023 at 3:12:16 AM UTC-7 Tobias Diez 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, 
>

[sage-devel] bug in invariants_of_degree

['Martin R' via sage-devel]

I need help with

https://github.com/sagemath/sage/issues/35684

Is Ben Hutz still around?

Martin

-- 
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/f847636c-96da-499c-bd79-eef578f8dd92n%40googlegroups.com.

Re: [sage-devel] VOTE: Follow NEP 29: Recommended Python version

[Dima Pasechnik]

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  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. hom

[sage-devel] VOTE: Follow NEP 29: Recommended Python version

[Tobias Diez]

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.