[Python-Dev] Another case for frozendict (original) (raw)

R. David Murray rdmurray at bitdance.com
Wed Jul 16 16:24:45 CEST 2014

On Wed, 16 Jul 2014 14:04:29 -0000, dw+python-dev at hmmz.org wrote:

On Wed, Jul 16, 2014 at 09:47:59AM -0400, R. David Murray wrote:

> It would be nice to be able to return a frozendict instead of having the > overhead of building a new dict on each call. There already is an in-between available both to Python and C: PyDictProxyNew() / types.MappingProxyType. It's a one line change in each case to return a temporary intermediary, using something like (C): PyINCREF(self->dict) return self->dict; To return PyDictProxyNew(self->dict); Or Python: return self.dct To return types.MappingProxyType(self.dct) Which is cheaper than a copy, and avoids having to audit every use of self->dict to ensure the semantics required for a "frozendict" are respected, i.e. no mutation occurs after the dict becomes visible to the user, and potentially has hash called.

> 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. Avoiding crashes seems a better use for a read-only proxy, rather than a hashable immutable type.

Good point. MappingProxyType wasn't yet exposed when I wrote that email code.

--David

More information about the Python-Dev mailing list