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 <sebast...@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 <sho...@gmail.com> > > > wrote: > > > > On Sun, Nov 1, 2020 at 7:47 PM Stefan van der Walt < > > > > stef...@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
