PEP 841 – Adding Frozen Syntax to Optimize Immutable Types

PEP 841 – Adding Frozen Syntax to Optimize Immutable Types | peps.python.org

Following system colour scheme

Selected dark colour scheme

Selected light colour scheme

Author: Donghee Na , Nikita Sobolev Discussions-To: Discourse thread Status: Draft Type: Standards Track Created: 20-Jul-2026 Python-Version: 3.16 Post-History: 20-Jul-2026

Table of Contents Abstract

Motivation

Rationale Syntax, not a builtin call

Why f{...}

Specification Grammar

AST

Semantics

Bytecode

The optimization pipeline

Backwards Compatibility

How to Teach This

Impact on the Standard Library

Reference Implementation

Rejected Ideas Alternative spellings

Freezing methods

Abstract

This PEP proposes frozen display syntax: f{1, 2, 3} evaluates to a frozenset, and f{'a': 1} evaluates to a frozendict. Because immutability is guaranteed by the syntax itself rather than inferred from usage, the compiler can treat frozen displays as first-class citizens of its optimization pipeline: constant displays are folded into a single LOAD_CONST with an exact result type at compile time and cached in .pyc files.

Motivation

Python has display syntax for its mutable containers but none for its immutable ones. Today an immutable set must be written as frozenset({1, 2, 3}) and an immutable mapping as frozendict({'a': 1}). Each of these:

builds a mutable set or dict, then copies it into the immutable type.

looks up the name frozenset or frozendict at runtime on every execution.

cannot be easily optimized by the compiler, because either name may be rebound and the call may have arbitrary side effects, or value can be of unexpected type for the optimization, value can be non uniquely referenced.

CPython already hints at the opportunity: the peephole optimizer rewrites a constant set display into a frozenset, but only as the right operand of in. Assign the same display to a variable and the optimization is gone. The root cause is that the compiler can never prove immutability of a set or dict display, so it must rebuild it on every execution. A display whose semantics guarantee immutability removes that barrier once and for all.

One of the goals of this PEP is to increase the use of immutable containers in CPython, preparing for a concurrent future in which free-threading and subinterpreters become significantly more common. Efficient creation of immutable data structures and convenient syntax would encourage the use of frozendict and frozenset. This would reduce bugs caused by accidental mutation of shared mutable containers while also improving performance. For example, subinterpreters already share frozenset objects, and there are plans to share frozendict objects as well.

Immutable container displays have been requested and discussed by the community several times, most recently in the frozenset and frozendict comprehensions thread on Discourse.

Rationale

Syntax, not a builtin call

Only syntax gives the compiler a semantic guarantee. A call to frozenset(...) can be shadowed, but a frozen display cannot. Every optimization described below follows from this single property.

Static analysis benefits in the same way. Today, tools that don’t perform semantic analysis must assume that frozenset(...) refers to the builtin. A frozen display turns that assumption into a syntactic guarantee, so analyzers can treat the result as immutable with full confidence. This holds even for purely syntactic tools that perform no name resolution.

Linters and formatters can automatically rewrite frozenset({1, 2, 3}) and frozendict({1: 2}) to be f{1, 2, 3} and f{1: 2} on newer Python versions.

Why f{...}

The f prefix reads as frozen, mirroring the familiar f-string prefix convention. Sharing the letter with f-strings is not a problem: strings are immutable too, so either way an f prefixed expression evaluates to an immutable value. f{ is a syntax error in all current Python versions, so the syntax is fully backward compatible. The tokenizer emits a single FLBRACE token for f{, so f {1} (with a space) remains an error and there is no ambiguity with the name f or with f-strings.

Specification

Grammar

Our goal is to make new syntax and grammar identical to existing set and dict syntax and grammar rules.

New alternatives are added to atom, mirroring set and dict displays and comprehensions:

fset: FLBRACE star_named_expressions '}' fsetcomp: FLBRACE star_named_expression for_if_clauses '}' fdict: FLBRACE [double_starred_kvpairs] '}' fdictcomp: FLBRACE kvpair for_if_clauses '}'

f{1, 2, 3} is a frozenset display.

f{'a': 1, 'b': 2} is a frozendict display.

f{} is an empty frozendict, mirroring {}.

Star unpacking follows the existing displays: f{*xs} is a frozenset display (like {*xs}) and f{**d} is a frozendict display (like {**d}).

Comprehensions are supported: f{x for x in xs} is a frozenset comprehension and f{k: v...

PEP 841 – Adding Frozen Syntax to Optimize Immutable Types

Related Articles

(no title)

Scientists reverse brain aging, with a nasal spray

NHS apologises and admits Palantir have access to identifiable patient data

AI has torched the market for junior programmers

Al Vigier: Canada's AI strategy shouldn't include secret Palantir bills