[Python-Dev] Add a frozendict builtin type (original) (raw)

Guido van Rossum guido at python.org
Fri Mar 2 03:31:41 CET 2012

On Thu, Mar 1, 2012 at 6:13 PM, Yury Selivanov <yselivanov.ml at 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 ongeneratereport(context):  data = yield fetchfinancialdata(context)  ... In the above example, 'fetchfinancialdata' 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)

More information about the Python-Dev mailing list