I’m personally a CalVer fan when deprecations and other notice periods are involved, so +1 on a 2026 3.26.0 release from me (and I agree with the PEP’s reasoning for choosing that approach as the least disruptive way of getting a calendar reference into the version number).
While the PEP specifically mentions making EOL dates easier to calculate (once you’re aware of the scheme, you’ll know that 3.26 will go EOL in 2031), using CalVer makes everything easier to translate into calendar time rather than counting versions and looking up when they will be (or were) released.
- setting your minimum compatible Python version to 3.12 in 2024 is actually making an aggressive assumption regarding version adoption and support. The less-than-12-months-old age of the release will be more obvious to folks considering making 3.26 their baseline in 2027. (Not a hypothetical example, I actually made a mistake along those lines when setting up a work project a couple of months ago and only corrected it last week when a new feature brought in a new dependency that didn’t fully support Python 3.12 yet)
- warnings for hard deprecations specify a future release when the deprecated feature will go away entirely. When the warning says
This will go away in 3.15, it isn’t immediately obvious how long you have to do something about it. When the warning instead saysThis will go away in 3.26(and you’re aware the versioning is CalVer based), you know you’ve got at least a year to do something about it, but will need to make changes after that.
(Tangent: while I don’t think it should be part of this PEP, there may even come a time when the text represention of the version number is sometimes written like “Python3 26.0” rather than always being written as “Python 3.26.0”. Something to consider for folks that find the fixed 3. prefix before the year a bit odd to look at)