> 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: arch...@mail-archive.com
