On Thu, Mar 1, 2012 at 6:13 PM, Yury Selivanov <yselivanov...@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
