Thanks for proposing this! I’d like to suggest something that, despite being a new feature, would benefit from being considered in the initial PEP (or at least initial implementation).
I assume an everyday use pattern for a frozendict would be: 1) prepare some data in a mutable dict. 2) convert to frozendict, discard the original. 3) spawn threads/interpreters/coroutines that read the frozen&shared version.
We need the mutable version in step 1 because we may want to build the data structure stepwise. Step 2 is potentially expensive in time and peak memory. Assuming it’s common to get rid of the mutable version (because after startup the concurrent system will only need the frozen one), you’re copying the entire thing and doubling the memory needs while that happens.
Something that would help with that is an in-place transformation from dict to frozendict. That could be possible by switching the ob_type from PyDict_Type to PyFrozenDict_Type… assuming that both have the same memory layout. In the current implementation that doesn’t happen, but it’s so close that I don’t think it would be hard to achieve. With that, you could have a freeze() method in e that mutates it into a frozendict (and you may want to have the same method in frozendict implemented as a no-op).
typical usage would be:
shared_data = build_complicated_dict()
shared_data.freeze()
start_serving_requests(shared_data) # spawns threads/subinterpreters/etc
This would often halve memory usage on startup and would shave some startup time.
Would this make sense?