We should aim to have an ecosystem where Python releases are usable day 1 and where it is easy for users to test their code prerelease if they want to.
Running this on the top 15000 PyPI packages (thanks hugovk!), we see on day 1, 1289 packages explicitly support Python 3.14 (as opposed to 994 for 3.13)
It’s also interesting to look only at packages with version-specific wheels. Often the lack of a version specific wheel is a hard blocker for users (compared to pure Python packages, where explicit support might just mean an extra entry in the test matrix and adding the classifier). Here we see on day 1 that 347 packages have wheels that support Python 3.14 (as opposed to 178 for 3.13)
I said this last year too, but every time one of those lines moves, it’s because someone somewhere did something in response to a new Python version, and made that labour freely available on the internet — this will never not be insanely cool to me.
This includes projects that support cp313t, which is why the graph starts near 50 in April. It’s difficult to use Hugo’s tracker before then so the graph doesn’t continue back to the release of Python 3.13.
The slope very clearly changes with the release of Python 3.14 rc1 and cibuildwheel 3.1. (cibuildwheel 3.1 enabled Python 3.14 builds by default). Spot checking a few releases after the rc1 date shows that a lot of them do use cibuildwheel
