Highlights of Python 3.12 Release: Flexible f‑strings, New Debugging API, Subinterpreter GIL, and Type‑Annotation Enhancements

Python 3.12.0 was officially released as a stable version.

Main changes

More flexible f‑string parsing (PEP 701)

Support for the buffer protocol (PEP 688)

New debugging/profiling API (PEP 669)

Independent subinterpreter GILs (PEP 684)

Performance optimisations such as PEP 709 and support for the BOLT binary optimiser, expected overall speed‑up of about 5%

Improved error messages

Support for Linux perf to report Python function names during tracing

Type annotations

New syntax for generic classes (PEP 695)

New override decorator for methods (PEP 698)

More flexible f‑string parsing (PEP 701)

The new release removes several original restrictions on f‑strings, allowing them to be parsed as regular literals with a dedicated parser, which simplifies maintenance and benefits both end‑users and library authors.

Previously, f‑strings had limitations such as:

Inability to use quote characters inside the expression part. <code>>> f'Magic wand: { bag["wand"] }' ^ SyntaxError: invalid syntax</code>

Backslashes were prohibited in f‑string expressions, leading to syntax errors. <code>>> f'Magic wand { bag[\'wand\'] } string' SyntaxError: f-string expression portion cannot include a backslash</code>

Comments could not appear inside f‑string expressions. <code>>> f'''A complex trick: { bag['bag'] # recursive bags! }''' SyntaxError: f-string expression part cannot include '#'</code>

Other languages allow nested interpolation without escaping, e.g.: <code># Ruby "#{ "#{1+2}" }" # JavaScript `${${1+2}}` # Swift "\(1+2)" # C# $"{$"{1+2}"}"</code>

The Python team recognised that these restrictions added unnecessary complexity and decided to give f‑strings a regular literal syntax with a dedicated parser.

Current f‑string implementation tokenises them as STRING tokens and then post‑processes, which incurs high maintenance cost, prevents use of the new PEG parser’s error‑message improvements, and makes it harder for alternative Python implementations to stay compatible.

Furthermore, the separate f‑string parser blocks other implementations (e.g., PyPy) from benefiting from official syntax changes and enhanced diagnostics.

Developers can look forward to a smoother experience with the new f‑string handling.

Creating a GIL for each subinterpreter (PEP 684)

PEP‑684, proposed by Eric Snow, creates a separate Global Interpreter Lock for each subinterpreter, enabling true parallelism in Python.

Python 3.12 does not yet include a “no‑GIL” build; the Python team plans to add an experimental no‑GIL build in Python 3.13.

Below is a promotional section (translated):

Long‑press or scan the QR code to get a free Python public course, which includes hundreds of gigabytes of learning material such as e‑books, tutorials, project templates, source code, and more.

Click “Read original article” for more details.