Repository navigation
Bump requires-python default to >=3.12 per SPEC 0 #785
Description
The template currently sets requires-python = ">=3.10" in the generated pyproject.toml (and python_version = "3.10" in [tool.mypy] / py-version = "3.10" in [tool.pylint]).
Per SPEC 0, Python 3.10 reached its recommended drop date in Q4 2024 and Python 3.11 in Q4 2025. As of today (Q2 2026), the SPEC 0-compliant minimum is Python 3.12 (released Oct 2023, drop date Q4 2026).
I understand from #537 that the template intentionally sets a conservative floor and projects are expected to raise it themselves. However, the current default is now two minor versions behind the ecosystem recommendation, which may give new projects a false sense that >=3.10 is still appropriate.
Proposal:
- Bump the generated
requires-pythonto>=3.12 - Update
python_versionin[tool.mypy]andpy-versionin[tool.pylint]accordingly - Update the classifiers list to start from
3.12 - Update the CI matrix lower bound from
"3.11"to"3.12"
Alternatively, consider a periodic update policy (e.g. bump each time a new cookie release is tagged) to keep the default aligned with SPEC 0.
Activity
henryiii commentedon May 4, 2026
We currently follow Official CPython EoL. We drop every October, usually within a day or two of EoL.
While I should note that I personally really dislike SPEC 0 for several other reasons too123, I believe regardless it is the wrong policy for a new project template. The reason SPEC 0 works is because stable, long-lived projects (like all the signees) work just fine if you get an older version. More than half of users (using NumPy's stats) are on versions of Python that SPEC 0 doesn't support, but on an older Python, you get an older NumPy, that's fine. It causes some weird issues, especially in the packaging space (locking solvers, for example, combine with SPEC 0 to break newer versions of Python by downloading old versions of packages! Uv has special handling or otherwise every package using numpy would get stuck on old versions that don't have Python 3.14 wheels). And when something important does come out, it causes issues.
For a new package, getting an older version of a package doesn't work, since there is no older version of a package - you are excluding over 50% of your potential user base. So I think a package that wants to support SPEC 0 should first get a stable release, then increase the minimum version.
Also, it's much easier to increase the version (to 3.12) that it is to lower it back to 3.10.
I'd be fine to add a mention of 3.12+ being the SPEC 0, but probably with the key idea above (that it only works for stable projects or projects that are fine to not pick up users on older Pythons).
Footnotes
It drives a wedge in the ecosystem between "Scientific" and "all others", us vs. them. As someone who is on both sides, it is really sad to see. It only exists because of NEP 29, which itself only exists due to the ridiculously long extension of the EoL for Python 2.7, but that's long history at this point. The "ecosystem" recommends 3.10+, because we are in the Python ecosystem. ↩
I was at the first Scientific Python Developer Summit and specifically asked to be part of the group that worked on SPEC 0, but was never allowed to be part of the discussion (that's where it was moved from 42 months to 36 months!) ↩
I believe SPEC 0 had quite a bit to do with killing PyPy, since they can't stay under 36 months behind. ↩