On Mon, May 6, 2024 at 6:46 AM Sebastian Berg <sebast...@sipsolutions.net> wrote:
> On Mon, 2024-05-06 at 09:17 +1000, Matti Picus wrote: > > On 05/05/2024 11:32, Mark Harfouche wrote: > > > > but to me it makes sense to support it for the > > large 2.0 release. > > The release will not be without problems rippling throughout the community. SPEC0 effectively asks downstream packages to: "Focus on Python 3.10 in 2024". But the introduction of "numpy 2.0" without updated downstream packages will surely break some. If these breakages occur, packages will have to think about whether or not to backport a release for those stuck on Python 3.9. This is something that was identified as a potential risk https://github.com/numpy/numpy/issues/26191 and you have all been very proactive in helping resolve the issues. I'm asking that you let Python 3.9 support disappear with 1.26, and not "drop a final version" before you decide to move on with 3.10+ only. On the list above is, Scikit-image, which I am a core developer of, and you have all identified as being compatible with Numpy 2.0 starting 0.23.1 does not have a CPython 3.9 build for 0.23.1 on pypi. https://pypi.org/project/scikit-image/0.23.1/#files It also lists as being compatible with numpy >=1.22 in its dependencies as this was understood to be the best practice at the time https://github.com/scikit-image/scikit-image/blob/v0.22.x/pyproject.toml#L29 Thus a project that uses Python 3.9 + pip + scikit-image will type pip install scikit-image and this can pull in numpy 2.0 I sadly haven't followed too closely with the full list of fixes for numpy 2.0 that were introduced in the 0.23.1 release, but I'm not looking forward to explaining to users why "Python" broke "again" on python 3.9. Scikit-image is an active project, with many eyes on it, and it seems many fixes for Numpy2 were already in the 0.22.0 release, but smaller projects will not have been so proactive. I think it is late anyway and NumPy always had a slightly longer > support period and that seemed fine especially since NumPy is low in > the stack. > > The SPEC was written to give the community that precedence and show > that many agree with you (and numpy endorses it). > Maybe the "endorsed by" list should rather be grown to strengthen the > argument instead? > I am asking that Numpy be included in the list of packages that adhere to it making the whole SPEC stronger. "Endorsed" but not adhered to is a much weaker argument than: "this is what numpy follows", "if the policy is good enough for them is good enough for us". It's very difficult to convince others when they see numpy as not following things, so they say "well its working now, lets just keep the CIs the same". It only grows the support burden for the strained open source we have (our time).
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
