The best new features and fixes in Python 3.14

The first beta release of Python 3.14 is now available. This article presents a rundown of the most significant new features in the next version of Python and what they mean for Python developers.

Major new features in Python 3.14

These are the most significant new features in Python 3.14:

Template strings

Deferred evaluation of annotations

Better error messages

A safe external debugger interface to CPython

A C API for Python runtime configuration

“Tail-call-compiled” interpreter

Template strings

We’ve long used f-strings in Python to conveniently format variables in a string. Python 3.14 introduces an even more advanced feature in this vein, template strings as defined in PEP 750.

A template string, or t-string, lets you combine the template with a function that operates on the template’s structure, not just its output. You could write a template handler that allows all variables placed in the template, or only variables of a specific type, or only variables that match some output, to be manipulated at output time. You could also handle the variables and the interpolating text as separate, differently typed objects.

For instance, if you have the template t'My name is {user_name}, and I'm from {user_locale}', you could have the variables user_name and user_locale automatically cleaned of any HTML before display. You could also perform transformations on the My name is and and I'm from portions of the output automatically, as those would be tagged with the special type Interpolation.

Template strings will make it far easier to write template engines, e.g., Jinja2, or to duplicate much of the functionality of those template engines directly in Python without the overhead of third-party libraries.

Deferred evaluation of annotations

Type annotations in Python have historically been evaluated “eagerly,” meaning when they’re first encountered in code. This made it difficult to do things like forward references for a type—e.g., to have a class method that takes a parameter hinted with another type that isn’t defined at that point in the module:

class Thing:
def frob(self, other:OtherThing):...
class OtherThing:...

Code like this would typically not pass linting. The workaround would be:

class Thing:
def frob(self, other:'OtherThing'):...
class OtherThing:...

Or you could use from __future__ import annotations.

With Python 3.14, annotations for objects are now stored in “annotate functions,” which are available through an __annotate__ attribute. This attribute returns the annotation for a given object when it’s needed, so annotations can be evaluated lazily by linters or even evaluated at runtime.

The annotationlib module provides tools for inspecting these new annotations at runtime or as part of a linting process.

If you’re currently using from __future__ import annotations as your workaround for handling deferred annotations, you don’t need to change anything just yet, although this directive is deprecated and will be removed entirely in future Python versions (most likely sometime after 2029).

Better error messages

Over the last several Python revisions, error messages have been improved and polished in many ways. This tradition continues with Python 3.14.

The biggest improvement: Unknown terms that closely match Python keywords now elicit suggestions. For example:

forr a in b:
^^^^
SyntaxError: invalid syntax. Did you mean 'for'?

Many other error improvements also have been rolled in:

Issues with unpacking, where there is a mismatch between the expected and received number of items, now have more detailed errors in more cases than before.

Misplaced elif blocks generate their own specific error message.

Statements that illegally combine ternary assignment and control flow (e.g., x = a if b else pass) now generate detailed error messages.

Incorrectly closed strings will elicit suggestions for completing the string.

A safe external debugger interface to CPython

Attaching an external debugger to the CPython interpreter comes at the cost of a lot of runtime overhead, and potential safety issues. Plus, you can’t attach a debugger to CPython spontaneously. In order to use an external debugger, you have to launch CPython with the debugger already attached.

With Python 3.14, a new debugger interface provides hooks into the CPython interpreter for attaching a debugger without changing its execution. You can use Python’s pdbdebugging module to attach to another Python process (by way of its process ID) and perform interactive debugging on the target process without having to restart the process with the debugger attached.

Aside from the added convenience, the new debugger interface also makes it easier for third parties to write better and more robust debugging tools. They will no longer need to inject their own custom code into the interpreter, which can be brittle and produce new bugs.

A C API for Python runtime configuration

The Python configuration C API provides a C API to let users set or get information about the current configuration of the Python interpreter, using Python objects rather than C structures. This way, the interpreter can be configured directly from Python itself, making it easier to write Python-level tools to make runtime changes to interpreter behavior.

The Python configuration C API is part of a general cleanup of CPython internals and APIs, including the APIs for how CPython is initialized. Note that C users can always drop back to the lower-level APIs if they need them.

Easier ways to use `except` for multiple exceptions

If you want to catch multiple exceptions in a try/except block, you have had to use parentheses to group them:

try:
flaky_function()
except (BigProblem, SmallProblem):...

With Python 3.14, you can simply list multiple exceptions separated by commas:

try:
flaky_function()
except BigProblem, SmallProblem:...

The original syntax still works, of course, but the new syntax means a little less typing for a common scenario.

‘Tail-call-compiled’ interpreter

The CPython interpreter in Python 3.14 can use a feature in C code that uses tail calls between functions. When compiled with a C compiler that supports these features, CPython runs slightly faster. Note that this feature isn’t the same thing as enabling tail call optimizations in the Python language; it is an internal optimization for the CPython interpreter. Python developers don’t need to do anything except upgrade to Python 3.14 to see a benefit.

Unfortunately, the original estimated performance improvements for this change turned out to be wildly off, due to a compiler bug in Clang/LLVM19 (since fixed in subsequent releases). The performance improvement falls in the range of 3% and 5%, well short of the 9% to 15% speedup originally reported. As with any optimization like this, you’ll want to run your own benchmarks to see how well your applications perform.