On Thu, Mar 1, 2012 at 6:13 PM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
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.
That sounds *very* far-fetched. You're pretty much designing a new language variant. It's not an argument for burdening the original language with a data type it doesn't need for itself. You should be able to prototype what you want using an advisory subclass (if you subclass dict and add __slots__=[] to it, it will cost very little overhead) or using a custom extension that implements the flavor of frozendict that works best for you -- given that you're already using greenlets, another extension can't be a bid burden. -- --Guido van Rossum (python.org/~guido)