[Python-ideas] Revisiting Immutable Mappings
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:
> > 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
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