[Python-ideas] Revisiting Immutable Mappings

Steven D'Aprano steve at pearwood.info
Thu Oct 11 02:39:57 EDT 2018

On Thu, Oct 11, 2018 at 01:27:50PM +1100, Chris Angelico wrote:


[Cameron Simpson]
> > Well, if it were called frozendict, indeed not. It should act like dict.
> >
> > So:
> >
> >   def frozendict(**kw):
> >       return MappingProxyType(kw)
> >
> > You could make an argument for that (or a slightly heftier version
> > accepting the various things dict accepts).

How would we make the opposite argument? That [frozen]dict *shouldn't* 
accept the same constructions that dict actually does?

Seems to me that since we've proven the utility of the various 
constructor signatures that regular dicts already support, the addition 
of "read-only" doesn't change that.

Now for the limited use-cases that MappingProxyType was originally 
designed for, as a wrapper around an existing dict, it made historical 
sense for it to only support a single dict argument. After all, it is a 
proxy, so there needs to be a dict for it to proxy.

But if we promoted it to a real mapping, not just a proxy, or introduced 
a new read-only mapping, it seems to me that the full dict constructor 
interface ought to be a no-brainer.

> > But not everything needs a special name.
> >
> Point of note: A mapping proxy is NOT immutable; it is merely read-only.
> A frozendict type, if it's meant to parallel frozenset, ought to be
> hashable (subject to the hashability of its members, of course)

Good point! That's exactly the sort of difference between 
MappingProxyType and a true frozendict that I was looking for.

So there's still a use-case for a true frozendict.

> Interestingly, frozenset isn't a subclass of set. I was going to say
> that a frozendict ought to be a dict, but maybe that isn't so
> important. 

If there were a subclass relationship between frozendict and dict, it 
ought to be equivalent to this:

py> issubclass(collections.MutableMapping, collections.Mapping)

but having two independent types works for me too.

> Which might make a simple pure-Python frozendict actually
> pretty easy.

There's historical precedent: sets (and frozensets?) were initially 
introduced as a std library module, and only later elevated to builtins.

I would be +1 for a frozendict module in 3.8, and if it proves 
sufficient useful to elevate to a builtin, that can happen in 3.9 or 


More information about the Python-ideas mailing list