On Mon, May 6, 2024 at 10:42 PM Oscar Benjamin <oscar.j.benja...@gmail.com> wrote:
> On Mon, 6 May 2024 at 19:59, Aaron Meurer <asmeu...@gmail.com> wrote: > > > > On Mon, May 6, 2024 at 6:34 AM Mark Harfouche <mark.harfou...@gmail.com> > wrote: > > > > > > 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. > > > > I don't understand NumPy supporting Python 3.9 means you have to also. > > A downstream dependent only has to support at most the versions you > > do. If NumPy dropped Python 3.9 but you wanted to keep it that would > > be a problem, but the reverse isn't because scikit-image depends on > > NumPy, not the other way around. > > A downstream package needs to provide updates for all the same Python > versions as its dependencies because otherwise e.g. a NumPy 2.0 > release for CPython 3.9 breaks dependent packages that no longer > support 3.9. Those projects then need to add back support for older > Python versions at the same time as putting out an urgent > compatibility release. Perhaps usually this is not such an issue but > particularly for an intentionally compatibility breaking release > sending it out to more than the usual range of Python versions is not > helpful for downstream. > I think this is an important argument indeed. The initial "follow SPEC 0" is not really relevant, but let's focus on the practical issue at hand. When a user types `pip install numpy scikit-image` in a Python 3.9 environment, where numpy 2.0 would support 3.9 and scikit-image 0.23 does not, then the end result will be that numpy 2.0 and scikit-image 0.22 (incompatible!) will be installed. This is undesirable. This problem could have been avoided by proper use of upper bounds. Scikit-image 0.22 not including a `numpy<2.0` upper bound is a bug in scikit-image (definitely for ABI reasons, and arguably also for API reasons). It would really be useful if downstream packages started to take adding upper bounds correctly more seriously. E.g., SciPy has always done it right, so the failure mode that this thread is about doesn't exist for SciPy. That said, this ship has sailed for 2.0 - most packages don't have upper bounds in some or all of their recent releases. So, I think I'm in favor of dropping Python 3.9 support after all to prevent problems. It is late in the game, but I do see that we're going to cause problems for packages that have already dropped 3.9, and I don't yet see an issue with dropping 3.9 for numpy 2.0 now. Does anyone see a potential failure mode if we go that way? Cheers, Ralf
_______________________________________________ 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
