[Python-ideas] Revisiting Immutable Mappings
philip.martin2007 at gmail.com
Wed Oct 10 22:28:32 EDT 2018
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 at cskk.id.au> wrote:
> On 10Oct2018 20:25, Philip Martin <philip.martin2007 at 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.
> 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.
> Cameron Simpson <cs at cskk.id.au>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas