PEP 2026: Calendar versioning for Python

[hugovk (Hugo van Kemenade)]

@thatbirdguythatuknownot

How would this affect sys.version_info? Would it also jump from (3, 14, ...) to (3, 26, ...)?

Yes, it would continue to report the version:

>>> sys.version_info
sys.version_info(major=3, minor=26, micro=0, ...)
>>> sys.version
'3.26.0 (v3.26.0:..., Oct 1 2026, 12:50:24) [...]'
>>> platform.python_version()
'3.26.0'
>>> platform.python_version_tuple()
('3', '26', '0')

@bwoodsend

I think the November release and its resultant off by almost one error is already enough nuance that I’d send people the Python release schedule page URL (or tell them to run norwegianblue python) instead of trying to explain it.

Nitpick: October release, but I get your point, and thanks for the norwegianblue plug

I will add that there are many alphas, betas, and release candidates during the release year, at least 10. We very much want people to be aware the release is coming, to get involved and start testing and reporting bugs before the big October release so we can fix them.

For example, during the beta phase, third-party library maintainers are strongly encouraged to test, and it’s extremely important to get as much exposure as possible.

@ncoghlan

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.

Yes, this is an excellent point.