[Python-Dev] Another case for frozendict
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:
def __init__(self, *args, **kwargs):
self._map = dict(*args, **kwargs)
self._hash = ...
yield from self._map
def __getitem__(self, 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