Python 3.13 End of Life: Dates and How to Upgrade

Python 3.13 reaches end of life in October 2029 and moved to security fixes only on 1 October 2026. What that means, when to move, and what breaks.

Python 3.13 reaches end of life in October 2029, and since 1 October 2026 it has received security fixes only. That leaves almost three years before you have to move, so the upgrade is a planning decision rather than an urgent one.

For every version, see the Python end-of-life dates page. Older versions are covered in Python 3.12 end of life and Python 3.11 end of life.

Python 3.13 dates

The dates come from PEP 719 and the Python Developer’s Guide. Python 3.13 received bugfix releases for about 24 months, against about 18 months for 3.11 and earlier versions, and 3.14 and 3.15 follow the same 24-month pattern. After the final bugfix release, security updates are source-only and provided as needed until about five years after the first release.

What was in 3.13

• A new interactive interpreter based on code from the PyPy project, with multiline editing, colour by default, and F1, F2 and F3 keys for help, history and paste mode.
• An experimental free-threaded build with the GIL disabled, in a separate executable usually called python3.13t. Its notes warn to expect a substantial single-threaded performance hit. See free threading explained.
• An experimental JIT compiler (PEP 744), disabled by default, with modest gains at that stage. See the Python 3.15 JIT for how it has progressed.
• 19 “dead battery” modules removed (PEP 594), including cgi, cgitb, crypt, imghdr, pipes and telnetlib, plus lib2to3 and the 2to3 tool.

The full tour is in what is new in Python 3.13.

When to move on

Staying on 3.13 until your dependencies and CI images are ready for the next version is reasonable. The strongest triggers are a library dropping 3.13, a feature you need, or a platform policy that requires a version still receiving bugfix releases.

What breaks going from 3.13 to 3.14

• Removed APIs: the asyncio child watchers (AbstractChildWatcher, get_child_watcher and the related classes, deprecated since 3.12); the ast.Num, ast.Str, ast.Bytes, ast.NameConstant and ast.Ellipsis aliases of ast.Constant; pkgutil.get_loader and pkgutil.find_loader; and urllib.request.URLopener and FancyURLopener.
• Lazy annotations: annotations are no longer evaluated when a function, class or module is defined. Code that reads __annotations__ directly may need the new annotationlib module, for example annotationlib.get_annotations with the FORWARDREF format. The What’s New page says working code from older versions will mostly not need changes.
• Multiprocessing: on Unix platforms other than macOS the default start method changed from fork to forkserver. Code that relied on inheriting state through fork needs multiprocessing.set_start_method("fork") or a redesign.

You can see the start method change by asking each interpreter:

$ python3.13 -c "import multiprocessing; print(multiprocessing.get_start_method())"
fork

$ python3.14 -c "import multiprocessing; print(multiprocessing.get_start_method())"
forkserver

This was checked on Linux. Test with warnings as errors in a clean environment: python -W error -m pytest.

Upgrade checklist

1. Add the new version to your CI matrix first, and keep 3.13 until it passes.
2. Create a fresh virtual environment on the new version and reinstall.
3. Fix deprecation warnings. Ruff’s UP rules help with syntax modernisation.
4. Search for multiprocessing use and for code that reads __annotations__.
5. Raise requires-python only when you are ready to drop 3.13.