I created https://github.com/numpy/numpy/pull/21601 to update NEP29 to address PEP602.
I'm not sure what the procedure for updating the NEP is. What I wrote may be too editorial, we could amend it to "PEP602 changed cadence, we are not reacting." with no explanation as well. Tom On Wed, May 25, 2022 at 10:41 PM Aaron Meurer <asmeu...@gmail.com> wrote: > > I have seen problems popping up already in a few places with latest > numpy not supported what is still the most commonly used Python version > (don't have links, sorry - but they were real packaging-related issues). So > I don't think it makes sense to shorten the time window. I also don't think > there's a need to drop one version that's urgent - it's some effort and CI > time, but the balance is decent right now. > > It's hard to say the balance is decent right now if the faster cadence > isn't even in full effect yet (as I noted in my original email). > > Generally I would say that dropping support only means that users of > older versions would simply need to use an older version of the > library. > > However this: > > > We cannot do that (yet, at least). Failing to publish wheels for a > supported Python version on a major OS is far worse than dropping support > completely. This will remain true until the time that Pip starts defaulting > to wheels-only and never picks the sdist if there's an older release for > that platform + Python combo. > > sounds like if even the latest version doesn't support a given CPython > version (and has CPython-versioned wheels), then pip installing it > will fail. Is that correct? > > > There was a lot of discussion around how big the window should be with > 42mo being about in the middle of what people advocated for. I am aware of > institutions that are on an every-other Python upgrade pattern (py37 -> > py39 -> (expected) py311) so always having at least 3 Pythons in the window > is important. Based on what we have seen so far, I still think 42mo is a > good choice, but do not think we have seen it in operations long enough to > draw any conclusions (the downside of year-scale planning is you need to > wait years to see if it worked out like you expected!) and hence do not > think we should make any changes to the time window for another few years. > That said, I am currently sympathetic to making the window longer and > against making it shorter. > > The reason I brought this up is because we were looking at whether it > makes sense to use NEP 29 for SymPy. Obviously we aren't bound to > using it, but given this apparent discrepancy in the text (which still > exists), I thought I would mention it here. But I will say that from > my point of view, supporting more Python versions is a burden. Having > more builds on CI means longer wait times to merge PRs. And having to > wait longer for new Python features is also annoying. > > Aaron Meurer > _______________________________________________ > 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: tcasw...@gmail.com > -- Thomas Caswell tcasw...@gmail.com
_______________________________________________ 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
