On Thu, May 9, 2024 at 12:28 AM Thomas Caswell <tcasw...@gmail.com> wrote:
> I think the spirit of NEP 29 is to pick your supported Python's when you > pick a target release date and you should then stick to it (to avoid "we > delayed so long we are over a cliff" decisions like this one). > That's true I believe. > We did NEP29 around the same time that Python went from 18 to 12 month > releases (my memory is that the cadence change was being considered but not > set). If Python is targeting an 18mo release cycle, then a 36mo window + > 2mo delayed Python release could land you in only supporting one version of > Python which seems too few (again, my memory could be a bit off). I was > not at the meeting where SPEC 0 was discussed, > Same here, I wasn't at that meeting so am unsure. I only got added to SPEC 0 as a co-author at the end because it's mostly a copy of NEP 29. "change in release cycle" is probably right as the motivation though. > but I suspect that the narrowing is to better align with an integer number > of Python releases while always hitting at least 2 versions of Python. > At least 3, right? 36 months is always 3 minor versions. > ---- > > It is worth considering that CPython has both a concept of "bugfix" (which > is 18mo) and "security" (which is 42mo and source-only) support. It is > arguable that by having "new feature" support and binary release > targeting a given version of Python for 36mo we are supporting a given > minor version of Python longer than upstream [speaking for myself I would > sign onto a proposal to do security release against the last version of our > libraries for all versions of Python that still have security support]. > > ---- > > > So only 30% of users have Python 3.10+ or newer. Most smaller or newer > projects can more than double their user base by supporting 3.8+. I could > even argue that 3.7+ is still helpful for a new project. Once a library is > large and stable, then it can go higher, even 3.13+ and not hurt anyone > unless there's a major development. > > I have the exact opposite view of Henry here, I think for new projects you > should be very aggressive and only support the newest Python version as you > don't have any users (so do not have to be responsible yet)! > I think what you do as a new project author totally depends on your goals and priorities. Either way, the argument that only so few users "have a new Python" seems a bit off-target. That's not how people think - they look for new packages to use when they need functionality, and once they find something that fits their needs, they make it work. Nor are the statistics reflective of usage needs, especially for manylinux - it's more that production deployments stay on the same version of Python for their own lifetime I suspect. But such deployments also pin all their dependencies, so they're irrelevant to new versions/projects. It gets ever-easier to install new Python versions, with pyenv/conda/etc. The "my single Python install comes from python.org and I'm using the same one because I am afraid to upgrade" is much less of an issue than it was 10 years ago. And it's caused mostly by users having knowledge gaps. So yes it can be a pain for them, but they'll have to learn at some point anyway. Same for "my old HPC cluster uses ..." - it's often an even older Python anyway, and you'll have tons of reasons why you don't want your cluster-installed stack - learn to use Spack or Conda, and you'll be much happier in the long run. --- Back to the topic of dropping 3.9 here: there seem to be some minor concerns. Tom is right about the spirit of NEP29/SPEC0. And Sebastian is partially right I think: not about `pip install scipy-image==0.22`, because that should be picking 0.22.1 plus an older numpy; but `==0.22.0` instead cannot be fixed anyway, and that's perhaps a more common way of spelling an `==` constraint. So the last-minute dropping will at most have a marginally useful impact. Since Mark has started working on doing a single release of scikit-image supporting Python 3.9 ( https://github.com/scikit-image/scikit-image/pull/7412), perhaps we can close the book on this request now, and decide to not change anything? I.e., we do release with 3.9 support as planned. 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
