[Python-Dev] Expose dictproxy through collections rather than the types module?

Nick Coghlan ncoghlan at gmail.com
Sat Apr 21 17:42:47 CEST 2012

On Sun, Apr 22, 2012 at 12:43 AM, R. David Murray <rdmurray at bitdance.com> wrote:
> On Sat, 21 Apr 2012 23:09:08 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Since it's not very discoverable that way, would anyone object if I
>> moved things around so it was exposed as collections.MappingProxy
>> instead? The main benefit to doing so is to get it into the table of
>> specialised container types at the top of the collections module docs
> The short answer is yes, someone would mind, which is why it is where it
> is.  Read the ticket for more: http://bugs.python.org/issue14386.

No worries. Someone was asking on python-ideas about creating an
immutable ChainMap instance, and I was going to suggest
collections.MappingProxy as the answer (for future versions, of
course). I was surprised to find it squirrelled away in the types
module instead of being somewhere anyone other than a core dev is
likely to find it.

I personally suspect the lack of demand Raymond describes comes from
people just using mutable dicts and treating them as immutable by
convention - the same way Python programs may have "immutable by
convention" objects which don't actually go to the effort needed to
fully prevent mutation of internal state after creation. Some objects
would be more correct if they did that, but in practice, it's not
worth the hassle to make sure you've implemented it correctly.

Still, it doesn't bother me enough for me to try to persuade Raymond
its sufficiently valuable to make it public through the collections


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list