Cameron,

That's a good suggestion. Ultimately, if there are not enough various use cases for a frozendict class, I think we could add something like this as an example recipe similar to the recipe section in itertools. I would be hesitant to add a quick shim to the standard library as I can't think of another instance where a developer calls a function expecting a specific class, and receives a different class. I'm happy to draft up some documentation if we decide to take this route because there aren't enough use cases. It would be great though to hear what other use cases developers have for a frozendict to ultimately decide whether this is the case.

On Wed, Oct 10, 2018 at 9:01 PM Cameron Simpson <cs@cskk.id.au> wrote:

On 10Oct2018 20:25, Philip Martin <philip.martin2007@gmail.com> wrote:
>Steven, that's a great idea, and I would be 100% up for your suggestion to
>have types.MappingProxyType renamed to frozendict.

I'm not for the rename, myself. Though I'd not be against a frozendict
factory in builtins, a tiny shim for MappingProxyType.

>However, the differences
>in the behavior of MappingProxyType's constructor versus dict's would make
>the API's behavior confusing IMO. For example, MappingProxyType(x=5, y=10)
>throws a TypeError. I don't think most people would expect this.

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). Or... you could just keep
such a thing in your personal kit as a trivial way to spell
"frozendict". One could argue for the above as a nice example to live in
the docs perhaps.

But not everything needs a special name.

Cheers,
Cameron Simpson <cs@cskk.id.au>