[Python-Dev] Another case for frozendict

Eric Snow ericsnowcurrently at gmail.com
Wed Jul 16 16:27:51 CEST 2014

On Wed, Jul 16, 2014 at 7:47 AM, R. David Murray <rdmurray at bitdance.com> wrote:
> After I hit send on my previous message, I thought more about your
> example.  One of the issues here is that modifying the dict breaks an
> invariant of the API.  I have a similar situation in the email module,
> and I used the same solution you did in regex: always return a new dict.
> It would be nice to be able to return a frozendict instead of having the
> overhead of building a new dict on each call.  That by itself might not
> be enough reason.  But, if the user wants to use the data in modified form
> elsewhere, they would then have to construct a new regular dict out of it,
> making the decision to vary the data from what matches the state of the
> object it came from an explicit one.  That seems to fit the Python zen
> ("explicit is better than implicit").
> So I'm changing my mind, and do consider this a valid use case, even
> absent the crash.


A simple implementation is pretty straight-forward:

class FrozenDict(Mapping):
    def __init__(self, *args, **kwargs):
        self._map = dict(*args, **kwargs)
        self._hash = ...
    def __hash__(self):
        return self._hash
    def __len__(self):
        return len(self._map)
    def __iter__(self):
        yield from self._map
    def __getitem__(self, key):
        return self._map[key]

This is actually something I've used before on a number of occasions.
Having it in the stdlib would be nice (though that alone is not
sufficient for inclusion :)).  If there is a valid use case for a
frozen dict type in other stdlib modules, I'd consider that a pretty
good justification for adding it.

Incidentally, collections.abc.Mapping is the only one of the 6
container ABCs that does not have a concrete implementation (not
counting types.MappingProxyType which is only a proxy).


More information about the Python-Dev mailing list