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.
Well, yes, what I’m suggesting is a mutation method in dict which is a mutable data structure. It’s as dangerous as dict.clear() or dict.update(), which Python already has. And it requires the same kind of discipline to use (mutate to setup, don’t share / don’t mutate in a concurrent environment). We already expect Python devs using concurrency to be aware of the risks of shared mutable data and to manage them to avoid the same “nasty debugging issues”, so this wouldn’t be introducing a particularly new problem.
I understand that benefits go beyond performance, but one of the touted benefits is “safely share dictionaries across thread and asynchronous task boundaries”, so I am thinking what can make this proposal more successful in enabling that at a low cost.
And I perfectly understand if the PEP authors don’t want to introduce this early on, but it would be nice if at least the initial implementation didn’t close the door on this possibility.