I posted very early reference implementation draft here: [WIP] Reference implementation: `frozendict` / `frozenset` literals and comprehensions by sobolevn · Pull Request #152820 · python/cpython · GitHub
I’ve always seen list/tuple treated as a mutable/immutable pair of Sequence types. The language of PEP 814 (in a section related to the topic of this thread!) supports this:
We consider that [a dict freezing] method can be added later if needed, but it doesn’t have to be added right now. Moreover, if such method is added, it would be nice to add a similar method for list/tuple and set/frozenset.
3 Likes
This is one of two main list/tuple differences. The other one is that tuples often have a fixed structure. See for instance how the typing module reflects it. Type hints for tuples differ from hints for lists: typing > tuples. For the same reason we have a namedtuple, but not namedlist.
The relationship list/tuple is thus not exactly analogous to set/frozenset case. In my consideration that’s (another) reason against introducing f[...].
Adding another literal just for the concept of “frozen” feels a bit tacked on to me, like we’re trying to introduce let into the language but specifically for 2 or 3 types.
I also think prioritizing shorter syntax for the sake of not wrapping is unnecessary. If you have a comprehension that wraps, chances are a separate generator function is more readable anyway.
Some third-party frameworks have their own collection types as well, so frozenset and frozendict aren’t alone in not having unique syntax.
2 Likes
Another possible variation is with a keyword inside the brackets :
{frozen a for a in iterable}
{frozen k: v for k, v in items if foo(k)}
1 Like
I originally wrote my post mentioning list[T] and tuple[T, ...] as the pair, but felt that the typing syntax was unnecessary to make my point. Clearly I was mistaken, lol