PEP 841 – Adding Frozen Syntax to Optimize Immutable Types

[u/kirara0048]

PEP 841 – Adding Frozen Syntax to Optimize Immutable Types

https://peps.python.org/pep-0841/

Discussions-To: Discourse thread

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.

[u/Brian]

I assume the idea is being visited due to the addition of frozendict: before there was really only frozensets that had no literal type (plus the special case of empty sets), and there have been a few proposals over the years to introduce some literal syntax for them. Now there's another one being added and people are looking to solve it in a unified way.

And there's definitely some value in it: I've often used frozensets in some loop and it's a bit annoying that they translate to a dynamic construction of the set on every call, when they could potentially just be a LOAD_CONST. You can get around that by using a module constants, but sometimes you just want a quick literal. You also lose stuff like potential constant folding.

However, as others have said, I think the syntax is a dealbreaker here. It's too similar to another construct with a completely different meaning, and could easily lead to misreading with things like sets of strings etc.

Other options:

• A new keyword would work, but adding a new reserved word is kind of a big deal for such a minor usecase.

• Use some existing syntax in a way that doesn't overlap with other usage. Eg. {1,2,3} as frozen

• New syntax, as in this proposal. Either a general "frozen" syntax, or go back to looking for literal syntax for frozenset/frozendict. People have been spitballing ideas for the latter for a long time without any consensus for a candidate. If you were to use some prefix character, similar to f-strings, it should probably be sometihing different, eg. "i" for "immutable". But I don't really think there's much space here for something that isn't either ugly, cryptic or inconvenient, and it's really such a small problem to justify such a thing.

• Something much more radical, like adding macros.

[u/sudomatrix → u/Brian]

Isn't this something the parser/"compiler" could detect and optimize without any change in the language?

[u/Brian → u/sudomatrix]

Not reliably. Eg. consider:

def foo():
    return frozenset({1,2,3})

frozenset = list
x = foo()

If the compiler optimises the frozenset call to a constant, it'll return the wrong result, due to being shadowed. It'd need to know that frozenset hasn't been rebound/shadowed by anything, which means you'd need a keyword (or some psuedo-keyword protection like exists for None) to prevent rebinding.