Hacker News Reader

Comment by munro | Hacker News Reader

Big ask, but can we wait to release until X number of packages are supported before releasing? And stay in RC until then? No pyarrow :(

View on HN

Not a great idea, IMHO. Lots of package maintainers are not at all interested in explicitly supporting unreleased versions of Python. I would certainly be one of them.

That said, Python releases generally don't introduce syntax-breaking changes. APIs are sometimes deprecated, but these have large windows that give maintainers plenty of advance notice. Years, typically. Practically all 3.10 code should run fine on 3.11, including your pyarrow.

Another thing to consider: the Python community is historically really bad at updating to the "latest and greatest". This [1] resource suggests that 80% of Python versions in the wild are Python 3.6-3.8!!

[1] https://w3techs.com/technologies/history_details/pl-python/3

I think this site is specifically keying in on the "Programming Language :: Python :: 3.11" PyPI classifier... While many packages haven't been updated to include this classifier, if you were to run all of the unit tests for all of the "Top 360" libraries on 3.11, I'd be willing to bet 350+ would pass without failure.

Author here: yep.

Many of the gray projects listed never even specify the minor number. Looking at setuptools, they only list Python :: 3.

If you go back to https://pyreadiness.org/3.8/ there are 20% of packages not explicitly supported, many from the top 100 list, anyone using these packages know this is not a concern. (Going back even further in versions you start to see dropped support instead)

Deducting these 20% should give a more accurate picture, and even then I’d bet most other packages work anyway, like you say.

> Big ask, but can we wait to release until X number of packages are supported before releasing? And stay in RC until then?

No, that’s silly.

(1) There’s no reason for something that otherwise is ready for stable to stay in RC because an arbitrary number of edternal packages aren’t ready to say they are ready for it, and

(2) No user actually benefits from X number of packages being ready, they benefit from the specific packages they depend on being ready. So its best for them to track them, and upgrade only when all the specific packages they need support the new version.

Reply on news.ycombinator.com