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@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@gmail.com>
> > wrote:
> > > On Sun, Nov 1, 2020 at 7:47 PM Stefan van der Walt <
> > > stefanv@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@python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> >
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion