[Numpy-discussion] NumPy 1.20.x branch in two weeks

Mark Harfouche mark.harfouche at gmail.com
Tue Nov 3 09:17:54 EST 2020


Juan made a pretty good argument for keeping 3.6 support in the next
scikit-image release, let me try to paraphrase:

- Since nobody has made the PR to explicitly drop python 3.6 from the
scikit-image build matrix, we will continue to support it, but if somebody
were to make the PR, I (Juan) would support it.

As for supporting PyPy: it already exists in the build matrix AFAICT.
Breaking PyPy would be a deliberate action, as opposed to an accidental
byproduct of dropping CPython 3.6.

On Mon, Nov 2, 2020, 13:50 Sebastian Berg <sebastian at sipsolutions.net>
wrote:

> On Mon, 2020-11-02 at 06:49 -0600, Juan Nunez-Iglesias wrote:
> > I like Ralf's email, and most of all I agree that the existing
> > wording is clearer.
> >
> > My view on the NEP is that it does not mandate dropping support, but
> > encourage it. In my projects I would drop it if I had use for Python
> > 3.7+ features. It so happens that we want to use PEP-593 so we were
> > grateful for NEP-29 giving us "permission" to drop 3.6.
> >
> > I would suggest that 3.6 be dropped immediately if there are any open
> > PRs that would benefit from it, or code cleanups that it would
> > enable. The point of the NEP is to short-circuit discussion about
> > whether it's "worth" dropping 3.6. If it's valuable at all, do it.
> >
>
> Probably the only thing that requires 3.7 in NumPy at this time is the
> module level `__getattr__`, which is used only for deprecations (and to
> make the financial removal slightly more gentle).
> I am not sure if PyPy already has stable support for 3.7 yet? Although
> PyPy is maybe not a big priority.
>
> We don't have to support 3.6 and I don't care if we do. Until this
> discussion my assumption was we would probably drop it.
>
> But, current master is tested against 3.6, so the main work seems
> release related. If Chuck thinks that is no hassle I don't mind if
> NumPy is a bit more conservative than NEP 29.
>
> Or is there a danger of setting a precedent where projects are wrongly
> expected to keep support just because NumPy still has it, so that NumPy
> not being conservative actually helps everyone?
>
> - Sebastian
>
>
> > Thanks all,
> >
> > Juan.
> >
> > On Mon, 2 Nov 2020, at 2:01 AM, Ralf Gommers wrote:
> > >
> > > On Mon, Nov 2, 2020 at 7:47 AM Stephan Hoyer <shoyer at gmail.com>
> > > wrote:
> > > > On Sun, Nov 1, 2020 at 7:47 PM Stefan van der Walt <
> > > > stefanv at berkeley.edu> wrote:
> > > > > On Sun, Nov 1, 2020, at 18:54, Jarrod Millman wrote:
> > > > > > I also misunderstood the purpose of the NEP.  I assumed it
> > > > > > was
> > > > > > intended to encourage projects to drop old versions of
> > > > > > Python.
> > >
> > > It was. It is. I think the NEP is very clear on that. Honestly we
> > > should just follow the NEP and drop 3.6 now for both NumPy and
> > > SciPy, I just am tired of arguing for it - which the NEP should
> > > have prevented being necessary, and I don't want to do again right
> > > now, so this will probably be my last email on this thread.
> > >
> > >
> > > > > Other
> > > > > > people have viewed the NEP similarly:
> > > > > > https://github.com/networkx/networkx/issues/4027
> > > > >
> > > > > Of all the packages, it makes sense for NumPy to behave most
> > > > > conservatively with depreciations. The NEP suggests allowable
> > > > > support periods, but as far as I recall does not enforce
> > > > > minimal support.
> > >
> > > It doesn't *enforce* it, but the recommendation is very clear. It
> > > would be good to follow it.
> > >
> > > > > Stephan Hoyer had a good recommendation on how we can clarify
> > > > > the NEP to be easier to intuit. Stephan, shall we make an
> > > > > ammendment to the NEP with your idea?
> > > >
> > > > For reference, here was my proposed revision:
> > > > https://github.com/numpy/numpy/pull/14086#issuecomment-649287648
> > > > Specifically, rather than saying "the latest release of NumPy
> > > > supports all versions of Python released in the 42 months before
> > > > NumPy's release", it says "NumPy will only require versions of
> > > > Python that were released more than 24 months ago". In practice,
> > > > this works out to the same thing (at least given Python's old 18
> > > > month release cycle).
> > > >
> > > > This changes the definition of the support window (in a way that
> > > > I think is clearer and that works better for infrequent
> > > > releases), but there is still the question of how large that
> > > > window should be for NumPy.
> > >
> > > I'm not sure it's clearer, the current NEP has a nice graphic and
> > > literally says "a project with a major or minor version release in
> > > November 2020 should support Python 3.7 and newer."). However happy
> > > to adopt it if it makes others happy - in the end it comes down to
> > > the same thing: it's recommended to drop Python 3.6 now.
> > >
> > > > My personal opinion is that somewhere in the range of 24-36
> > > > months would be appropriate.
> > >
> > > +1
> > >
> > > Cheers,
> > > Ralf
> > >
> > >
> > >
> > > _______________________________________________
> > > NumPy-Discussion mailing list
> > > NumPy-Discussion at python.org
> > > https://mail.python.org/mailman/listinfo/numpy-discussion
> > >
> >
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion at python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20201103/c8643df8/attachment-0001.html>


More information about the NumPy-Discussion mailing list