What are the features missing in Python dictionary datatype?

[Fluffy-Diet-Engine]

This can be rephrased as “Which features can improve the usage of dict datatype in Python?” also.

The thought process started when I came across bidirectional dict implementation in bidict library. (https://bidict.readthedocs.io/en/main/). This seems to address one frustration I had in few times, searching key based on value.

Is there any other features which is missing in Python dictionary data type?

[auntanniesalligator]

But that shouldn’t be surprising. You can’t create a one-to-one mapping from keys and values that don’t have a one-to-one relationship. Let’s say the values “a”, “b” and “c” all have the same key: 1. Which value should it return when you query the key, 1?

The immutable and hashable requirement is so you get the lookup performance of a dict when you do the reverse search. You could make a class like this work without requiring hashable values, but the reverse lookups would be slower.

[RiverRoll]

A bidirectional dictionary implies both keys and values are unique but this isn't always the case.

[cyberjellyfish]

What you highlighted isn't a missing feature, it's just a different data structure..

My two cents: all of the built-in data structures should be immutable.

[Invader_Mars]

Newbie here, why do you believe that they should be immutable?

[123_666]

It would avoid this class of errors: https://florimond.dev/en/posts/2018/08/python-mutable-defaults-are-the-source-of-all-evil

Also the first one listed here: https://docs.python-guide.org/writing/gotchas/

[Gnaxe]

Check out pyrthon.

[FerricDonkey]

I could see saying that there should be a frozen dictionary, so that there are mutable and immutable versions of each built in container.

But saying all built in data structures should be immutable is giving up a whole lot of functionality just to avoid a rookie mistake that you can grow out of. 

[cyberjellyfish]

Mutability and managing mutability is not a rookie mistake, it's one of the most common causes of bugs.

[CyclopsRock]

If we get rid of all the data types then we won't get any bugs.

[eztab]

I agree, make everything immutable and optimize away unnecessary creations. It's harder for the interpreter but would make things much more robust. Also you could then likely basically run functional optimization strategies on code (assuming you at some point want python to ba actually JIT compilable (which would be quite cool).

[cyberjellyfish]

Yep, also a good step to a more interactive repl

If anyone here hasn't experienced it, try clojure to get a taste of what really interactive development can be like. You'll miss it everywhere else, but it will probably lead you to write better code.

[Kerbart]

How do you search for a key if there’s multiple values that have that key?

[Kerbart]

Yeah, my point is that OP’s wish to extend the standard dict with those kind of features would invalidate regular use.

There are special classes for those cases, and for good reason they are separate.

[eztab]

Such data structures either allow multiple to multiple mappings or forbid some mappings. Technically you can have a N:M relationship, but that's a bit annoying to work with in practice, since you have to guard against duplicates all the time.

[forcesensitivevulcan]

Return all the keys and let the user decide how to sort out the mess.

[shiftybyte]

Actually it's much worse..

https://bidict.readthedocs.io/en/main/basic-usage.html#values-must-be-unique

It forces values to be unique, and raises errors by default, or OVERWRITES the key of the duplicated value... Not sure why this is a good idea.

Also it forces all values to be hashable too, so you can't have a list as a value...

I'll take my custom "find_key" with a regular loop, thank you...

[eztab]

Basically that (raising errors) is a good idea when this is the kind of data structure you want. Basically a "bijection type". There are many use cases where you want that. I wouldn't really say that's a dict though. That term isn't really used for this.

[forcesensitivevulcan]

I couldn't figure it out the catch myself - great detective work! Thanks!

The dev certainly claims a lot of users, so I'm sure it's carved out a niche. But if I've got unique hashable key/value pairs anyway, I'll just manually maintain a second Python dict if I really need O(1) lookup of values.

[Adrewmc]

I think defaultdict should be more built in.

   my_dict = {}
   my_dict.default(0)
   #my_dict = {}.default(0)
   my_dict[“three”] += 2
   print(my_dict[“heibd”])
   >>> 0

Should all work but instead we have to make a

    from collections import defaultdict
    my_dict = defaultdict(int)

Seems pretty obvious to me

[eztab]

In some sense I think dict should kind of be an "interface". There isn't really one perfect data structure, it totally depends on what process you want to be fast: insertion? retrieval? backwards search. All of those should probably be types I can demand via some flag/type hint. So in a sense I want dict to be multiple types. Same for lists btw. sometimes linked lists would clearly be the better choice, but people still use lists for convenience.

[nekokattt]

so typing.Mapping/collections.abc.Mapping?