PEP 814: Add frozendict built-in type

We can also make it a bit more generic and somehow check for the mapping protocol.

Without talking to the PEP authors I can guarantee that pprint would get updated if the PEP was accepted.

The potential issue with that is C code could do some shenanigans with the underlying data and invalidate that those two “copies” are the same. If you know you’re working with a frozendict you’re going to avoid bothering with copies anyway, so it shouldn’t be a big deal in the end.

But now you have made that dictionary frozen for everyone who holds a reference to it, which means side-effects at a distance in a way that could be unexpected (e.g. context switch in a thread and now suddenly you’re going to get an exception trying to mutate what was a dict a microsecond ago but is now frozen). That seems like asking for really nasty debugging issues just to optimize some creation time.

Remember this is not being pitched as a perf win, but as a way to lessen bugs in concurrent code because you can’t share immutable dicts write now. And we tend to try and design around programmer ergonomics more than perf and this suggestion seems to go against that general goal.

20 Likes