[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0

[Brigitta Sipőcz]

Hi,

Is there any way to know if other large libraries hasn't set an upper pin
in their last release but since then dropped python version support?

Brigitta

On Fri, 10 May 2024 at 07:47, Ralf Gommers  wrote:

>
>
> On Thu, May 9, 2024 at 12:28 AM Thomas Caswell  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: b.sipocz+numpyl...@gmail.com
>
___
NumPy-Discussion mailing list

[Numpy-discussion] Re: ANN: NumPy Fellowship Program & Sayed Adel as our first Developer in Residence

[Brigitta Sipőcz]

Wonderful news, congratulations Sayed!

Brigitta

On Thu, 1 Dec 2022 at 13:18, Ralf Gommers  wrote:

> Hi all,
>
> I'm excited to be able to share this announcement on behalf of the NumPy
> Steering Council. We have created a new program, the NumPy Fellowship
> Program, and offered Sayed Adel the very first Developer in Residence role.
> Sayed starts his 1 year tenure in that role today, and we are really
> looking forward to him working on NumPy full-time.
>
> We wrote a blog post about the program, and why we offered the role to
> Sayed: https://blog.scientific-python.org/numpy/fellowship-program/. I've
> copied the blog post content at the end of this email.
>
> In addition, here is some more detail on NumPy project finances that
> didn't make it into the blog post (which is likely to have a wider audience
> than the readership of this mailing list), but is quite relevant to share
> here:
>
> Over the past decade, NumPy has accumulated individual donations as well
> as payments from Tidelift. NumPy has been a fiscally sponsored project of
> NumFOCUS for a decade - meaning that NumFOCUS, as a 501(c)3 nonprofit,
> administers funds for NumPy. As a result, NumPy has accumulated funds for a
> long time - and those are now transparently administered on Open
> Collective . There you will see a
> "general fund", currently with a ~$23,000 balance, and two open "projects"
> with committed funding - one for the active CZI grant we have, and one for
> this new Fellowship Program. Guidelines for using those funds are described
> in https://numpy.org/neps/nep-0048-spending-project-funds.html.
>
> Finally it is worth pointing out that we are now able to solicit donations
> on Open Collective, and have added contribution tiers on the front page of
> https://opencollective.com/numpy. Until now, we have never actively
> solicited donations as a project, because the accounting support and
> transparent financial reporting was not in place. That has changed now
> though, so we are hoping that with guidelines to spend funds plus a
> concrete fellowship program that we're expecting to be quite impactful, we
> are now able to confidently tell people that if they donate to NumPy, we
> will manage their contribution well and translate it into more time for
> someone on the NumPy team to make NumPy better.
>
> Cheers,
> Ralf
>
>
> blog post content:
>
> The NumPy team is excited to announce the launch of the NumPy Fellowship
> Program and the appointment of Sayed Adel (@seiko2plus) as the first NumPy
> Developer in Residence. This is a significant milestone in the history of
> the project: for the first time, NumPy is in a position to use its project
> funds to pay for a full year of maintainer time. We believe that this will
> be an impactful program that will contribute to NumPy’s long-term
> sustainability as a community-driven open source project.
>
> Sayed has been making major contributions to NumPy since the start of
> 2020, in particular around computational performance. He is the main author
> of the NumPy SIMD architecture (NEP 38, docs), generously shared his
> knowledge of SIMD instructions with the core developer team, and helped
> integrate the work of various volunteer and industry contributors in this
> area. As a result, we’ve been able to expand support to multiple CPU
> architectures, integrating contributions from IBM, Intel, Apple, and
> others, none of which would have been possible without Sayed. Furthermore,
> when NumPy tentatively started using C++ in 2021, Sayed was one of the
> proponents of the move and helped with its implementation.
>
> The NumPy Steering Council sees Sayed’s appointment to this role as both
> recognition of his past outstanding contributions as well as an opportunity
> to continue improving NumPy’s computational performance. In the next 12
> months, we’d like to see Sayed focus on the following:
>
> SIMD code maintenance,
> code review of SIMD contributions from others,
> performance-related features,
> sharing SIMD and C++ expertise with the team and growing a NumPy
> sub-team around it,
> SIMD build system migration to Meson,
> and wherever else Sayed’s interests take him.
>
> “I’m both happy and nervous: this is a great opportunity, but also a
> great responsibility,” said Sayed in response to his appointment.
>
> The funds for the NumPy Fellowship Program come from a partnership with
> Tidelift and from individual donations. We sincerely thank both Tidelift
> and everyone who donated to the project—without you, this program would not
> be possible! We also acknowledge the CPython Developer-in-Residence and the
> Django Fellowship programs, which served as inspiration for this program.
>
> Sayed officially starts as the NumPy Developer in Residence today, 1
> December 2022. Already, we are thinking about opportunities beyond this
> first year: we imagine “in residence” roles that focus on developing,
> improving, an