[Python-Dev] Add a frozendict builtin type

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 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)


More information about the Python-Dev mailing list