On 2012-03-01, at 7:50 PM, Guido van Rossum wrote:
I think you should provide stronger arguments in each case why the data needs to be truly immutable or read-only, rather than just using a convention or an "advisory" API (like __private can be circumvented but clearly indicates intent to the reader).
Here's one more argument to support frozendicts. For last several months I've been thinking about prohibiting coroutines (generators + greenlets in our framework) to modify the global state. If there is a guarantee that all coroutines of the whole application, modules and framework are 100% safe from that, it's possible to do some interesting stuff. For instance, dynamically balance jobs across all application processes: @coroutine def on_generate_report(context): data = yield fetch_financial_data(context) ... In the above example, 'fetch_financial_data' may be executed in the different process, or even on the different server, if the coroutines' scheduler of current process decides so (based on its load, or a low priority of the coroutine being scheduled). With built-in frozendict it will be easier to secure modules or functions' __globals__ that way, allowing to play with features closer to the ones Erlang and other concurrent languages provide. - Yury